This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED
- From: Andrew Cagney <cagney at gnu dot org>
- To: Randolph Chung <randolph at tausq dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 01 Dec 2004 16:27:53 -0500
- Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED
- References: <20041123174937.GL9148@tausq.org> <41AA09F8.4020006@gnu.org> <20041128184141.GG6359@tausq.org> <41AA2D08.3030304@gnu.org> <20041129033013.GJ6359@tausq.org> <41AB3C1D.80509@gnu.org> <20041130065620.GT6359@tausq.org> <41AC88B2.5070501@gnu.org> <20041130164401.GV6359@tausq.org> <41ACA6BE.5080603@gnu.org> <20041130173841.GW6359@tausq.org>
Randolph Chung wrote:
well, first i want to understand the problem. because i'm still not
yet 100% convinced that step_through_delay will work. simply using the
"instruction_nullified" method in hppa-tdep as the "step_through_delay"
method certainly is not working...
When doing a stepi? step_through_delay certainly won't help when it
comes to doing a backtrace from the nullified instruction.
when doing a step.
I was thinking that STEPI might be easier to debug :-)
Anyway, trying modifying gdbarch_read_pc and unwind_pc (I suspect you
need to modify both - which is a bug) to read something like:
if (instruction nullified)
return next-pc
else
return this-pc
it should fool GDB into thinking that it's one instruction ahead of itself.
Andrew