From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2906 invoked by alias); 3 Feb 2009 09:21:05 -0000 Received: (qmail 2893 invoked by uid 22791); 3 Feb 2009 09:21:04 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,FB_WORD1_END_DOLLAR,J_CHICKENPOX_53 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Feb 2009 09:20:59 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n139KqiV031965; Tue, 3 Feb 2009 10:20:52 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n139KqMX010260; Tue, 3 Feb 2009 10:20:52 +0100 (CET) Date: Tue, 03 Feb 2009 09:21:00 -0000 Message-Id: <200902030920.n139KqMX010260@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: dje@google.com CC: gdb@sourceware.org In-reply-to: <20090201231819.A9FB61C7A19@localhost> (dje@google.com) Subject: Re: i386 int3 handling, running vs stepping References: <20090201231819.A9FB61C7A19@localhost> 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/msg00029.txt.bz2 > Date: Sun, 1 Feb 2009 15:18:19 -0800 (PST) > From: dje@google.com (Doug Evans) > > gdb is inconsistent in its handling of int3 instructions on x86. > > bash$ cat int3.S > .text > .global main > main: > nop > int3 > nop > hlt > > bash$ gcc -g -Wa,-g int3.S -o int3 > bash$ gdb int3 > (gdb) run > --> > 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? No, this is not a bug. It is how the architecture works. > I can argue either case, I don't have a preference per se. > > Trying things again, this time stepi'ing over the insn: > > bash$ gdb int3 > (gdb) start > [...] > Temporary breakpoint 1, main () at int3.S:4 > 4 nop > Current language: auto; currently asm > (gdb) si > 5 int3 > (gdb) si > 6 nop > (gdb) > > Note that int3 was stepping over without a SIGTRAP being generated. Yes, the SIGTRAP is eaten by gdb because it was an expected side-effect of single-stepping the instruction. The ptrace(2)/wait(2) interface traditionally used by debuggers can't really tell the difference between hitting a breakpoint and single-stepping. This could be overcome with some kernel hacking by making it possible to look at the signal code (probably already possible on recent Linux kernels). But I don't see a real reason to do that. > [I haven't tried setting a breakpoint at the int3 insn, but > GDB can know whether it's stepping over one of its own breakpoints > or an int3 that's part of the program, so I think(!) gdb can be consistent > here regardless.] GDB will interpret this as a normal breakpoint, and won't generate a SIGTRAP. > The only question I have is what should the value of $pc be after > hitting an int3 instruction during normal execution? (ie. no stepping, > no breakpoints). The address of the instruction immediately following the int3 instruction.