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

[Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>]

On Wed, 2010-08-18 at 20:28 +0200, Ulrich Weigand wrote:
> Matthew Gretton-Dann wrote:
> > However, I think there is a more fundamental issue to be solved in the
> > ARM backend.  For ARM (and possibly other architectures) you do not have
> > enough information in the PC to be able to accurately set a breakpoint,
> > you also need to know the instruction set in use at that address.
> > 
> > Currently this is being done in a fairly ad hoc and inconsistent fashion
> > by using bit-0 to indicate Thumb or ARM state.  But this troublesome to
> > maintain, and can make the debugger behave in a non-obvious manner to
> > the user.  I think it would be cleaner to change the interfaces to
> > various functions (for example breakpoint_from_pc) to take an
> > 'instruction set state' parameter as well as the pc (or change the pc
> > from a CORE_ADDR to a { CORE_ADDR pc; enum instruction_set isa; } pair),
> > but this would be a large scale change with impacts throughout the code
> > base - which probably makes it impractical, and certainly in need of
> > discussion.
> 
> Good point.  I think there are two potential longer-term options.  On
> the one hand, we've been planning to add support for multiple address
> spaces within a single process; this would imply that all gdbarch
> callbacks that get an address today also receive an address space
> identifier.  If we have that, we could create two address spaces to 
> represent the Thumb vs. ARM instruction space ...
> 
> Another option would be to actually have two separate *gdbarch*
> implementations for Thumb vs. ARM, and use the multi-architecture
> support to choose the proper architecture to use.  For frames,
> this would already be possible today using the frame-arch unwinder
> I've added for Cell support.  There is even a breakpoint-location
> architecture, but no way yet for the back-end to influence how
> this is selected ... that can be added, though.  (There may be
> other places where support is currently insufficient, of course.)
> 
> In fact, the latter option seems nice anyway since in several gdbarch
> callback we already basically have a big "if ARM vs. Thumb" switching
> between two quite different implementations.  Just having two different
> gdbarch's in the first place might actually simplify this ...

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?
Will the user still be able to see a backtrace with some frames in ARM
state and some in Thumb?

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.

Thanks,

Matt


-- 
Matthew Gretton-Dann
Principal Engineer - PDSW Tools
ARM Ltd