Re: [rfc] Strip Thumb bit from PC returned by arm_get_longjmp_target

Ulrich Weigand
2010-08-19T08:49:26Z

> Matthew Gretton-Dann wrote:
>
> > The problem with the patch is it removes what may be the only way we
> > have of telling the instruction state of the longjmp target. If you
> > have debugging information (mapping symbols at the very least)
> > everything is fine, but if you don't then how do you tell what the state
> > is? arm_pc_is_thumb does use this bit to detect the instruction state
> > (and arm_breakpoint_from_pc then uses this result to determine the
> > breakpoint type).
>
> Ah, I see. I was confused about just where the Thumb bit was supposed
> to be present and where not, sorry ...
>
> > In the case above I think the correct fix is to make
> > arm_adjust_breakpoint_address not strip out the address bits (which it
> > does when trying to work out whether we are single stepping through an
> > IT block).
>
> Does the patch below seem reasonable to you?

Actually, it turns out this new patch doesn't work. It leads to:

Breakpoint 4 at 0x84ec: file ../../../gdb-head/gdb/testsuite/gdb.threads/threxit-hop-specific.c, line 47.^M
(gdb) next^M
^M
Program received signal SIGTRAP, Trace/breakpoint trap.^M

This happens because GDB now no longer recognizes the PC address
when the breakpoint trap arrives. The PC is compared against
the breakpoint location's loc->address value -- which now has the
Thumb bit set, but the PC doesn't.

Note that while the Thumb bit gets removes in arm_breakpoint_from_pc,
this affects only loc->placed_address, not loc->address.

This seems to indicate that in fact, breakpoint addresses must
*not* have the Thumb bit set ...

Do you have a case where this works for you?