From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21227 invoked by alias); 1 Feb 2009 23:38:16 -0000 Received: (qmail 21219 invoked by uid 22791); 1 Feb 2009 23:38:16 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,FB_WORD1_END_DOLLAR,J_CHICKENPOX_53,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 01 Feb 2009 23:38:12 +0000 Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id n11Nc98A029425 for ; Sun, 1 Feb 2009 23:38:09 GMT Received: from rv-out-0506.google.com (rvbg9.prod.google.com [10.140.83.9]) by spaceape11.eur.corp.google.com with ESMTP id n11Nc4u6029619 for ; Sun, 1 Feb 2009 15:38:06 -0800 Received: by rv-out-0506.google.com with SMTP id g9so692126rvb.1 for ; Sun, 01 Feb 2009 15:38:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.134.10 with SMTP id h10mr1944095rvd.287.1233531484165; Sun, 01 Feb 2009 15:38:04 -0800 (PST) In-Reply-To: <20090201233251.GA27142@caradoc.them.org> References: <20090201231819.A9FB61C7A19@localhost> <20090201233251.GA27142@caradoc.them.org> Date: Sun, 01 Feb 2009 23:38: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/msg00003.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: > >> 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 can't see a plausible way around this, can you? The SIGTRAP is > identical to the one for PTRACE_SINGLESTEP - unless the kernel > annotates the siginfo differently? I haven't looked into siginfo, but can gdb look at the insn? [akin to displaced stepping handling]