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

Daniel Jacobowitz
2006-02-21T15:36:10Z

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] [+<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.