Re: RFA/ARM: Switch mode when setting PC

[Richard Earnshaw <rearnsha at arm dot com>]

> I guess I just see this differently.  The existing Linux ptrace
> interface also predates Thumb, so it's not surprising that it just
> writes what you give it into the PC register.  But I can't see any
> reason why I should change that.  The remote protocol is a very
> low-level protocol; the CPSR and PC are separate writeable registers,
> and I would find it extremely surprising if the sequence:
>   read CPSR
>   read PC
>   write PC
>   read CPSR
> 
> could return two different CPSR values.
> 
> Here's what I would find even more surprising.  The sequence:
>   read PC
>   write same value to PC
> 
> would suddenly switch me out of Thumb mode, since the bit is cleared in
> the PC!  This would break _all_ uses of the interface (either the sim
> interface or the ptrace interface) in Thumb mode.  Right now there are
> only problems if you are deliberately trying to mode switch.
> 
> In short, I think writing the PC should not change the CPSR, and if the
> client wants to change the mode they should do it explicitly.

You raise an interesting point.  I'd been thinking about it purely from 
the simulator's perspective, rather than in the wider context.

I've just had a conversation with some engineers in our debugger group to 
see if there was a specific opinion.

The consensus seems to be that you are right, the debugger must correctly 
set the 'CPSR' if it wants the inferior to switch states.

All this means that there are effectively 33 bits that have to be updated 
when the PC is written and a state change is needed.  This is complicated 
further by the fact that sometimes one of those bits needs to be 
manufactured, and at other times it doesn't.  (in fact, there can be 34 
bits if you include the CPSR 'J' bit, but let's not even think about going 
there).

For example, if the user writes a 32-bit value into the PC, the CPSR state 
probably shouldn't be changed (even if the bottom bit is altered) -- this 
is how ARM's debuggers behave.  However, if the user 'calls' a function 
that is in the 'other state', then the CPSR should be updated (and 
presumably restored afterwards).

I'm not sure if GDB has a way of separating these two cases.  It's an 
interesting problem.

As a final comment, when it comes to talking directly to real hardware 
(eg, via an ICE box), it isn't generally possible to update the CPSR by 
just writing to it (at least, not for the 'T' and 'J' bits); the only way 
of switching to Thumb state is via a BX instruction or with some other 
PC-modifying instruction that is documented to cause a state change (on 
ARMv4T that normally means 'movs PC, ...' or 'ldm ..., PC}^'; on v5 some 
loads to the PC can also be used).

R.