From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9838 invoked by alias); 2 Feb 2009 00:52:23 -0000 Received: (qmail 9828 invoked by uid 22791); 2 Feb 2009 00:52:22 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Feb 2009 00:52:15 +0000 Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n120qCpD019975 for ; Sun, 1 Feb 2009 16:52:13 -0800 Received: from rv-out-0506.google.com (rvfb25.prod.google.com [10.140.179.25]) by wpaz13.hot.corp.google.com with ESMTP id n120q9v7017457 for ; Sun, 1 Feb 2009 16:52:10 -0800 Received: by rv-out-0506.google.com with SMTP id b25so1356833rvf.39 for ; Sun, 01 Feb 2009 16:52:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.173.10 with SMTP id v10mr1984163rve.199.1233535929845; Sun, 01 Feb 2009 16:52:09 -0800 (PST) In-Reply-To: <20090201233251.GA27142@caradoc.them.org> References: <20090201231819.A9FB61C7A19@localhost> <20090201233251.GA27142@caradoc.them.org> Date: Mon, 02 Feb 2009 00:52:00 -0000 Message-ID: Subject: Re: i386 int3 handling, running vs stepping From: Doug Evans To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00004.txt.bz2 On Sun, Feb 1, 2009 at 3:32 PM, Daniel Jacobowitz wrote: > On Sun, Feb 01, 2009 at 03:18:19PM -0800, Doug Evans wrote: >> Program received signal SIGTRAP, Trace/breakpoint trap. >> main () at int3.S:6 >> 6 nop >> >> Note that $pc is the insn AFTER the int3. >> Question: Is this a bug? Should $pc point to the int3 instead? >> [whether that's achieved with decr_pc_after_break or whatever >> is a separate question] >> I can argue either case, I don't have a preference per se. > > I think it's right the way it is, and I know people take advantage of > this for hardwired breakpoints. > btw, i386-tdep.c:i386_displaced_step_fixup has this: /* If we have stepped over a breakpoint, set the %eip to point at the breakpoint instruction itself. (gdbarch_decr_pc_after_break was never something the core of GDB should have been concerned with; arch-specific code should be making PC values consistent before presenting them to GDB.) */ if (i386_breakpoint_p (insn)) { if (debug_displaced) fprintf_unfiltered (gdb_stdlog, "displaced: stepped breakpoint\n"); eip--; } Given that the pc should be left AFTER the int3 when stepping over it, do we want to delete this code?