Re: RFA/ARM: Switch mode when setting PC

Daniel Jacobowitz
2004-01-16T14:10:43Z

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.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer