Re: [RFC] Fix SW breakpoint handling for Cell multi-arch

[Pedro Alves <palves@redhat.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