From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10507 invoked by alias); 1 Feb 2009 23:18:35 -0000 Received: (qmail 10389 invoked by uid 22791); 1 Feb 2009 23:18:35 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,FB_WORD1_END_DOLLAR,J_CHICKENPOX_53,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; Sun, 01 Feb 2009 23:18:23 +0000 Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id n11NILIo000767 for ; Sun, 1 Feb 2009 15:18:21 -0800 Received: from localhost (ruffy.corp.google.com [172.18.118.116]) by zps78.corp.google.com with ESMTP id n11NIJtP021086 for ; Sun, 1 Feb 2009 15:18:20 -0800 Received: by localhost (Postfix, from userid 67641) id A9FB61C7A19; Sun, 1 Feb 2009 15:18:19 -0800 (PST) To: gdb@sourceware.org Subject: i386 int3 handling, running vs stepping Message-Id: <20090201231819.A9FB61C7A19@localhost> Date: Sun, 01 Feb 2009 23:18:00 -0000 From: dje@google.com (Doug Evans) 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/msg00001.txt.bz2 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? [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. 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. [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.] 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).