Re: RFA/ARM: Switch mode when setting PC

Richard Earnshaw
2004-01-16T17:28:33Z

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