RFC: Use the ARM CPSR as a fallback to determine ARM/Thumb

Daniel Jacobowitz drow@false.org
Tue Feb 21 16:10:00 GMT 2006


On Tue, Feb 21, 2006 at 11:05:13AM +0000, Richard Earnshaw wrote:
> I can sympathise... :-)  Also note that for a lot of ARM users,
> defaulting to ARM is exactly the wrong choice, since all their code is
> Thumb (with the possible exception of some start-up code and other small
> trampolines).  I think that guessing based on the current CPSR is a
> better guess than just ARM, if you can sort out the 'what we guessed
> last time we looked at this address problem...'.

OK, I will fix up the patch.

> > Maybe there should be a "set" option for the default when no symbol is
> > found, allowing the user to throttle this back to ARM-only if that works
> > better for them?
> 
> I certainly think we need a set option, but it's more complex than that,
> since I think it needs probably four states:
> 
> arm        - force to ARM mode even if things look otherwise.
> thumb      - force to Thumb mode even if things look otherwise.
> auto-arm   - Try to work it out, but guess ARM if unknown
> auto-thumb - Try to work it out, but guess Thumb if unknown
> 
> Another approach would be some augmentation to a memory-region type
> command, something like
> 
> add code-region [arm|thumb|auto-arm|auto-thumb] <base> [+<extent>|<limit>]

What I had in mind for this was:

set arm fallback-mode [arm|thumb|auto]

That is, continue to honor symbol information, but change the fallback
when we don't have symbols to arm, thumb, or current cpsr.

And maybe augment that with:

set arm force-mode [arm|thumb|auto]

This would also override symbol information.

This is basically the same as your first option, but spread out over
two variables.  How does that sound?

I'd rather avoid regions here; they're complicated, and not a very
useful way to describe arm/thumb mixing.  Hmm, software single step
probably gets very confused over mode changes; not going to touch that
right now though.

-- 
Daniel Jacobowitz
CodeSourcery



More information about the Gdb-patches mailing list