This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA/ARM: Switch mode when setting PC



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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]