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

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

Matthew Gretton-Dann wrote:

> Using two gdbarch objects seems reasonable, and also extends nicely if
> we decide to support the ThumbEE ISA as well (which is intended for JITs
> so gdb is unlikely to have any debug info to help it along).
> 
> However, I am concerned about a couple of things:
> 
> 1) What changes does this make to the user interface?  Can I user still
> say 'break main' and gdb will determine ARM or Thumb automatically?

That's the one piece I mentioned where common code support will have to
be added.  Basically, we'd need a gdbarch callback that gets the gdbarch
the breakpoint was parsed in, and the breakpoint's PC address (plus
address space, eventually), and would return the gdbarch to be used to
handle that particular breakpoint location.

> Will the user still be able to see a backtrace with some frames in ARM
> state and some in Thumb?

This mechanism already exists and is used for Cell debugging today: we
can install a frame architecture unwinder that, given a frame, returns
the architecture to be used for the next-outer frame.

> 2) This moves the decision what instruction set state a breakpoint is
> targetting from the time we set the breakpoint to the time the
> breakpoint is requested by the user.  Is this a reasonable thing to do?
> I think so - I don't expect code to change under the debugger's feet, so
> making the decision when we have most information available (at
> breakpoint request time) is the correct way to go.

Actually, it would move the decision to the point where the breakpoint
location structure is allocated.  This happens when the breakpoint is
initially requested, yes, but breakpoint locations are also recomputed
every time the available debug information changes (e.g. shared libraries
are loaded/unloaded).

Bye,
Ulrich

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