Re: RFA/ARM: Switch mode when setting PC

[Andrew Cagney <cagney@gnu.org>]

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

Hopefully not (well ignoring -tdep files).

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

The change wouldn't be tested, and would be more work.

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

What ever.

Andrew