This is the mail archive of the
mailing list for the GDB project.
Re: RFA/ARM: Switch mode when setting PC
If there's an explicit "set_resume_address", separate to write_pc, this
(gdb) set $r15 = 0x123
- target sees:
(gdb) call foo() OR (gdb) jump foo
- target, via "set_resume_address", sees:
and significantly no other write_pc calls.
And at this point, is write_pc used for anything besides
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
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,
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?