Re: RFA/ARM: Switch mode when setting PC

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jan 16, 2004 at 02:12:18PM -0500, Andrew Cagney wrote:
> Or a lack of design, Arm needs to ensure that it doesn't define PC_REGNUM.

OK, I'll keep that in mind.

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

Perhaps, in that case, we should have the PC as a pseudoregister.  That
would simplify a lot of arm-tdep.c.  Is it possible to use the existing
ARM compiler and simulator (and newlib) in 26-bit mode without a lot of
hassle, or would it be the work of months to make it happen?  I'm
reluctant to dig my fingers in too deeply if I can't test both code
paths.

> >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.
> 
> If there's an explicit "set_resume_address", separate to write_pc, this 
> should happen:
> 
> 	(gdb) set $r15 = 0x123
> 	- target sees:
> 		$r15=0x123
> 	(gdb) call foo()   OR (gdb) jump foo
> 	- target, via "set_resume_address", sees:
> 		$r15=&foo
> 		$ps&|=<magic-bits>
> 
> and significantly no other write_pc calls.

And at this point, is write_pc used for anything besides
DECR_PC_AFTER_BREAK?  I would prefer to add an adjust_pc_after_break,
and then possibly rename the existing write_pc.  Most of the write_pc
implementations we have currently are really set-resume-address
semantics.

On Fri, Jan 16, 2004 at 01:57:40PM -0500, Andrew Cagney wrote:
> >On Fri, Jan 16, 2004 at 09:10:40AM -0500, Daniel Jacobowitz wrote:

> >Is this patch OK (write_pc isn't deprecated yet!)?  Cleaning up the
> >existing DECR_PC_AFTER_BREAK handling is going to be a touchy job, and
> >I don't really want to try it today :)  I'll try to look into it later,
> >though.

> I was suggesting "two methods so that it's clear that this case only 
> applies when doing a jump".  This won't involve anything like 
> deprecating /removing decr_pc_after_break _+ write_pc but will involve 
> the addition of a new method like:
> 	set_resume_address (arch, targ or tpid or regs)
> that could somehow default to a legacy call to write_pc.  Significantly, 
> this will avoid making the changes conditional on the elimination of 
> decr-pc (your concern).
> 
> Why is this better?  It clearly separates the [apparently] legetimate 
> resume case from the decr-pc case.  This in turn opens the way for the 
> deprecate / delete decr-pc "write_pc" code while at the same time 
> ensuring that the work can't break the arm.

Sorry, but you did not answer my question.  My question was, are you
specifically objecting to this patch pending the, IMO tangentially
related, architectural cleanup?

I understand your suggested change and your reasoning for it, I just
don't understand your answer to my question.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer