From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5710 invoked by alias); 18 Nov 2004 16:21:12 -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 5601 invoked from network); 18 Nov 2004 16:21:03 -0000 Received: from unknown (HELO pippin.tausq.org) (64.81.244.94) by sourceware.org with SMTP; 18 Nov 2004 16:21:03 -0000 Received: by pippin.tausq.org (Postfix, from userid 1000) id CA909CE279; Thu, 18 Nov 2004 08:21:08 -0800 (PST) Date: Thu, 18 Nov 2004 16:21:00 -0000 From: Randolph Chung To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED Message-ID: <20041118162108.GK15714@tausq.org> Reply-To: Randolph Chung References: <20041118000159.GG15714@tausq.org> <419CB118.7080401@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <419CB118.7080401@gnu.org> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00376.txt.bz2 > I'm wondering about: > > # 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 I was too, but actually this seems to do something slightly different. single_step_through_delay seems to be asking: "does the current instruction have a delay slot"? This is used to tell gdb that if we wanted to do a step on a branch-insn-with-a-delay-slot, then after we step through the branch insn, we will step one more insn. Is that correct? The comment is confusing because it talks about "executing a delay slot" but at least mips-tdep.c, the only implementation of this method, doesn't test that. It tests "executing a branch insn with a delay slot". The new method i'm adding is a bit different though. The PA has a concept of "nullified" instructions. Based on the result of a previous instruction (which may or may not be a branch insn), the next instruction may be nullified. This is in many ways the precursor to the highly predicated insn model of IA64. By examining the insn at pc (or previous pc) you cannot tell whether the current insn is nullified. You can only tell that by examining processor flags. (Possibly on ia64 you would extract the predicate register from the current insn and examine the contents of that predicate register. I haven't looked at the details.) > I suspect that at one stage it was behaving like > single_step_through_delay, but was then changed to perform the same > operation unconditionally (i.e., when stopping from a cntrl-c say). GDB > trying to helpfully do a few extra steps after a cntrl-c bugs me :-) i was trying to figure out that piece of commented out code too and why it was changed. looked through cvs history but didn't find it. I'm not particularly fond of introducing new almost-arch-specific gdbarch methods either, but this does seem to be doing slightly different things than the existing ones. OTOH this is almost a "cosmetic" feature, so one alternative is to drop the INSTRUCTION_NULLIFIED logic completely.... randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/