From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11585 invoked by alias); 1 Dec 2004 06:19:43 -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 11523 invoked from network); 1 Dec 2004 06:19:32 -0000 Received: from unknown (HELO arwen.tausq.org) (64.81.244.109) by sourceware.org with SMTP; 1 Dec 2004 06:19:32 -0000 Received: by arwen.tausq.org (Postfix, from userid 1000) id C78B5111F2D; Tue, 30 Nov 2004 22:19:24 -0800 (PST) Date: Wed, 01 Dec 2004 06:19:00 -0000 From: Randolph Chung To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED Message-ID: <20041201061924.GZ6359@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> <20041129033013.GJ6359@tausq.org> <41AB3C1D.80509@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41AB3C1D.80509@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-12/txt/msg00011.txt.bz2 > >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) > > I'm not sure what you mean. What you describe sounds like the old > STEP_SKIPS_DELAY logic - a test on the _next_ instruction. The new > logic instead: > > # Return non-zero if the processor is executing a delay slot and a > # further single-step is needed before the instruction finishes. > M::int:single_step_through_delay:struct frame_info *frame:frame > > checks to see if the _last_ instruction put us into a delay slot. mmm... maybe i'm not reading the code correctly, but i still don't see how this will work for the hppa case. this predicate is used in two places: in proceed(), this only applies for the first insn at a "continue" or a "step"/"next", right? so in any case it doesn't do anything if you are stepping through a series of instructions and the first one is not a branch/delay slot insn. in handle_inferior_event(), the condition being checked is: if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected && gdbarch_single_step_through_delay_p (current_gdbarch) && currently_stepping (ecs)) trap_expected will not be set when you are doing a "step" with single stepping. possibly this works on mips because it uses software single step? but on hppa we have hardware single step, and as far as i can tell trap_expected is not set as we are stepping through instructions to get to the next line when doing a "step". this condition again seems to be more for the case when you hit a breakpoint at a branch insn with a delay slot and you want to determine how to single step off that branch. in the hppa case we have no breakpoints in this case. 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 -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/