Re: RFA/ARM: Switch mode when setting PC

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jan 16, 2004 at 04:54:30PM +0000, Richard Earnshaw wrote:
> 
> > 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.

Patch OK then?

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

Whew! :)

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

I believe that this will work at present, because setting $pc will not
go through write_pc.  There's some blind luck involved in this, though.

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

Really?  Interesting... I don't think GDB handles this at all at the
moment.  For both Linux userland GDB and Linux remote kernel GDB, this
is a non-issue; you can write the CPSR directly and it will be restored
at return from exception (via the SPSR and an ldm instruction).  This
works because the kgdb stub is implemented as an exception handler.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer