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

["Ulrich Weigand" <uweigand@de.ibm.com>]

> 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?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com