From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29952 invoked by alias); 18 Nov 2004 16:56:17 -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 29875 invoked from network); 18 Nov 2004 16:56:07 -0000 Received: from unknown (HELO server7.nfra.nl) (192.87.1.57) by sourceware.org with SMTP; 18 Nov 2004 16:56:07 -0000 Received: from juw15.nfra.nl [10.87.8.15] by server7.nfra.nl; Thu, 18 Nov 2004 17:55:29 +0100 Received: from juw15.nfra.nl (localhost [127.0.0.1]) by juw15.nfra.nl (8.12.2+Sun/8.11.1) with ESMTP id iAIGthCu026053; Thu, 18 Nov 2004 17:55:43 +0100 (CET) Received: (from kettenis@localhost) by juw15.nfra.nl (8.12.2+Sun/8.12.2/Submit) id iAIGthDa026050; Thu, 18 Nov 2004 17:55:43 +0100 (CET) Date: Thu, 18 Nov 2004 16:56:00 -0000 Message-Id: <200411181655.iAIGthDa026050@juw15.nfra.nl> From: Mark Kettenis To: randolph@tausq.org CC: cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <20041118162108.GK15714@tausq.org> (message from Randolph Chung on Thu, 18 Nov 2004 08:21:08 -0800) Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED References: <20041118000159.GG15714@tausq.org> <419CB118.7080401@gnu.org> <20041118162108.GK15714@tausq.org> X-SW-Source: 2004-11/txt/msg00377.txt.bz2 Date: Thu, 18 Nov 2004 08:21:08 -0800 From: Randolph Chung > 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? I think the description is misleading. 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 problem on MIPS is that if you trap on a delay slot, the processor backs up the PC to the preceding branch instruction. As a result, naively single-stepping will re-execute the branch instruction again and again. Therefore, operating systems and GDB's software single-stepping machinery will step over the delay slot, effectively executing two instructions in a row instead of one. Now if there would be a breakpoint-instruction in the delay slot, this won't work. That's why we had the STEP_SKIPS_DELAY macro that makes sure the single-step is done without any breakpoints inserted. This was replaced by single_step_through_delay which presumably will also be used on a new CRISv32 port. Another problem is when there is a breakpoint in the delay slot. Hitting it would thoroughly confuse GDB since after hitting the breakpoint instruction the PC will not point at the breakpoint, but at the branch instruction. Continuing from that point will hit the breakpoint again and again. I'm not sure the current code handles this correctly. 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.... Perhaps that isn't such a bad idea if it doesn't confuse GDB too much. Mark