Re: RFA/ARM: Switch mode when setting PC

Richard Earnshaw
2004-01-16T14:15:40Z

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