This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA/ARM: Switch mode when setting PC
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Richard dot Earnshaw at arm dot com, Andrew Cagney <cagney at gnu dot org>, gdb-patches at sources dot redhat dot com, rearnsha at arm dot com
- Date: Fri, 16 Jan 2004 17:27:58 +0000
- Subject: Re: RFA/ARM: Switch mode when setting PC
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw 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.