Re: RFA/ARM: Switch mode when setting PC

[Daniel Jacobowitz <drow at mvista 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer