Re: RFA/ARM: Switch mode when setting PC

[Richard Earnshaw <rearnsha at arm dot com>]

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

I'm happy with the ARM part, if you can convince Andrew that the MI part 
is ok.

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

In the past we've tried to distinguish R15 from PC.  This was especially 
useful in the legacy 26-bit mode where the CPSR bits *were* in R15.

This would probably all have been much simpler if I'd been able to 
complete my code for handling the banked register; sadly I never got far 
enough, and I think the code is probably too bit-rotten to be worth trying 
to resurrect directly at this point.

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

If you are talking directly to a core through a hardware channel such as 
an ICE, there's all sorts of restrictions and limitations.  It's usually 
the job of a further layer to map the high(ish)-level directives from the 
debugger onto commands that can be done on the target (in many instances 
you have to insert instructions directly into the core pipeline -- well 
the fetch unit -- and then clock them through).  It's not an area I know 
much about beyond the very basics.

R.