This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Fix SW breakpoint handling for Cell multi-arch
- From: Pedro Alves <palves at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 27 Aug 2015 16:43:16 +0100
- Subject: Re: [RFC] Fix SW breakpoint handling for Cell multi-arch
- Authentication-results: sourceware.org; auth=none
- References: <20150827115423 dot 571F824DD at oc7340732750 dot ibm dot com>
On 08/27/2015 12:54 PM, Ulrich Weigand wrote:
> Hi Pedro,
>
> a second major issue with Cell multi-arch debugging right now is related
> to the new target-side SW breakpoint handling. Cell uses linux-nat as
> primary target for the PowerPC side, which now returns true from the
> to_supports_stopped_by_sw_breakpoint hook.
>
> This works fine for the PowerPC side. However, when a breakpoint on the
> SPU side is hit, the kernel does *not* provide a siginfo with TRAP_BRKPT,
> but instead simply delivers a SIGTRAP without siginfo.
Does si_code indicate that it was a kernel-generated SIGTRAP (that is,
SI_KERNEL)? Wondering whether that would still be distinguishable
from trace/single-step traps and user sent SIGTRAPs. See comment and
table about x86's si_code in nat/linux-nat.h. I don't know whether
the SPU has to care about all the cases there, but I suspect
not (e.g., I'd assume SPU code can't exec?).
If not, then we'll have to cope... :-/ . Any chance the kernel gets
fixed, in order for some future gdb stop worrying about this? I was
hoping to get rid of the moribund locations heuristic at some point.
> The linux-nat
> target therefore does not recognize the breakpoint and does decrement
> the PC; this completely throws off infrun, which expects the target to
> have done this.
>
> The attached patch fixes this in the spu-multiarch target by overriding
> to_wait as well as to to_stopped_by_sw_breakpoint, and handles the SPU
> case there. This does seem to fix the problem for me.
>
> Does this look reasonable to you, or do you have any other suggestions?
Looks reasonable to me, if the suggestion above leads nowhere...
Thanks,
Pedro Alves