From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26560 invoked by alias); 1 Dec 2004 17:11:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26524 invoked from network); 1 Dec 2004 17:11:52 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 1 Dec 2004 17:11:52 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CZY0w-0002CN-8q; Wed, 01 Dec 2004 12:11:38 -0500 Date: Wed, 01 Dec 2004 17:11:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED Message-ID: <20041201171137.GA8037@nevyn.them.org> Mail-Followup-To: Randolph Chung , Andrew Cagney , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041201061924.GZ6359@tausq.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00021.txt.bz2 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