From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28176 invoked by alias); 29 Nov 2004 03:30:22 -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 28155 invoked from network); 29 Nov 2004 03:30:17 -0000 Received: from unknown (HELO localhost.localdomain) (64.81.244.109) by sourceware.org with SMTP; 29 Nov 2004 03:30:17 -0000 Received: by localhost.localdomain (Postfix, from userid 1000) id 1D43C43998; Sun, 28 Nov 2004 19:30:14 -0800 (PST) Date: Mon, 29 Nov 2004 03:30:00 -0000 From: Randolph Chung To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED Message-ID: <20041129033013.GJ6359@tausq.org> Reply-To: Randolph Chung References: <20041118000159.GG15714@tausq.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41AA2D08.3030304@gnu.org> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.6+20040722i X-SW-Source: 2004-11/txt/msg00504.txt.bz2 > If, when resuming the inferior, a double step is required, > single_step_through_delay will do the job. this is not possible to do in the general case though, because, sitting on the current insn at pc, you cannot necessarily determine if the next insn will be nullified or not. (in the current example, the nullification is always applied, but it can be conditional on some computation being done) > However, that doesn't solve the case of GDB encountering a frame > (inferior) that, be it through attach, cntrl-c, a signal, or a core > file, is already sitting on the above nullified instruction. The > corefile case being expecially nasty - trying to get a corefile to step > off a nullified instruction won't get you very far :-). I suspect that > the code will need to modify ``pc'' so that it either appears to be one > instruction behind (the "bv,n") or one instruction ahead (branch > destination) of what the registers indicate. oh, are you saying that: if we are looking at a corefile, and the current pc is sitting on a nullified insn that belonged to the next function, that we may not be able to do a backtrace correctly? > It might also be useful to check the SPARC. It has PC/NPC, delay slots, > and instruction nullification, so I'd expect similar problems. ok, i'll see if i can find a sparc machine to try to reproduce this problem there. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/