Re: RFA/ARM: Switch mode when setting PC

[Richard Earnshaw <rearnsha at arm dot com>]

> On Fri, Jan 16, 2004 at 12:43:46AM -0500, Andrew Cagney wrote:
> > >This patch fixes several failures in virtfunc.exp for arm-sim/-mthumb.  The
> > >problem is that the non-virtual thunk for pDe->vg() is emitted in ARM mode
> > >and called via _call_via_r2.  But the rest of the program is Thumb mode, 
> > >and
> > >nothing tells the simulator (or target; I haven't tested this on hardware
> > >yet but I expect the same result) to switch to ARM.  So it gets very
> > >confused.
> > >
> > >This is somewhat suboptimal in that if you want, for some reason, to call
> > >something marked as an ARM function with Thumb mode enabled you will have 
> > >to
> > >set $ps yourself _after_ setting $pc.  I think it's still a good idea,
> > >though.  OK?
> > 
> > (sorry, but I don't understand that paragraph - doesn't that code set 
> > the $ps after setting the $pc?)
> 
> Right.  But if you want to start a Thumb function in ARM mode you'll
> have to do:
>   (gdb) set $pc = start_of_function
>   (gdb) set $ps = $ps & ~0x20
> 
> > The ari contains this yellow card:
> > 
> > write pc
> > Replace write_pc() with get_frame_base_address or get_frame_id; at 
> > present the inferior function call code still uses this when doing a 
> > DECR_PC_AFTER_BREAK
> > 
> > the concern is with the way write_pc is being called to perform two 
> > different operations:
> > 
> > - decrement the pc just after the target stops
> > Arrrg!
> > - jump to a specific address
> > As with an inferior function call or jump.
> > 
> > I think it would be better to have two methods so that it's clear that 
> > this case only applies when doing a jump.
> 
> Well, it'd be better to rip out the current DECR_PC_AFTER_BREAK and
> handle it completely within the four (roughly) affected targets,
> thereby removing the overloading of write_pc.  IMVHO.
> 

Unless the "Thumb bit" is being stripped out by GDB, then I suspect that 
this is a bug in the gdb/simulator binding layer.  Any attempt to force 
the PC value by the debugger should be taken as a potential state change.  
If that is not happening, then all sorts of things may not work.

I've suspected that there is a problem in the way that gdb drives the 
simulator for a while now.

R.