Re: RFA/ARM: Switch mode when setting PC

Richard Earnshaw
2004-01-16T16:55:08Z

> 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.