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: Daniel Jacobowitz <drow at false dot org>
- To: Randolph Chung <randolph at tausq dot org>
- Cc: Andrew Cagney <cagney at gnu dot org>, gdb-patches at sources dot redhat dot com
- Date: Wed, 1 Dec 2004 12:11:38 -0500
- Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED
- References: <419CB118.7080401@gnu.org> <20041118162108.GK15714@tausq.org> <200411181655.iAIGthDa026050@juw15.nfra.nl> <20041123174937.GL9148@tausq.org> <41AA09F8.4020006@gnu.org> <20041128184141.GG6359@tausq.org> <41AA2D08.3030304@gnu.org> <20041129033013.GJ6359@tausq.org> <41AB3C1D.80509@gnu.org> <20041201061924.GZ6359@tausq.org>
On Tue, Nov 30, 2004 at 10:19:24PM -0800, Randolph Chung wrote:
> i experimented with another proposal which is to adjust the pc when we
> are at a nullified instruction. i modified target_read_pc () to return
> the previous (or next) pc when we are at a nullified instruction. this
> fixes some of the failures but causes new failures with the
> "recurse.exp" test. i need to investigate that some more. but teaching
> target_read_pc() to lie about the current pc seems to be suboptimal.
>
> lastly a comment about sparc -- i think the sparc case is simpler
> because it doesn't have conditional nullification. so looking at a
> particular insn you can always determine if the next insn will be
> nullified or not. this is not always the case for hppa.
Randolph,
Here's an off-the-cuff idea for you. Could you actually skip the
nullified instruction, if you had a hook in the right place? That is,
when a thread stops, if it is stopped at a nullified instruction,
forcibly move it to the next instruction before returning control to
GDB.
This is probably not feasible if you have to use single-stepping to end
up in the right place. If you can compute the right place and adjust
registers, though, it shouldn't be hard.
--
Daniel Jacobowitz