From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 787 invoked by alias); 2 Feb 2009 20:03:23 -0000 Received: (qmail 777 invoked by uid 22791); 2 Feb 2009 20:03:23 -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 20:03:19 +0000 Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id n12K3G9m024253 for ; Mon, 2 Feb 2009 12:03:17 -0800 Received: from rv-out-0506.google.com (rvbg9.prod.google.com [10.140.83.9]) by spaceape12.eur.corp.google.com with ESMTP id n12K3D3o004743 for ; Mon, 2 Feb 2009 12:03:14 -0800 Received: by rv-out-0506.google.com with SMTP id g9so1073803rvb.6 for ; Mon, 02 Feb 2009 12:03:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.141.16 with SMTP id o16mr2466716rvd.138.1233604993316; Mon, 02 Feb 2009 12:03:13 -0800 (PST) In-Reply-To: <20090202042459.GA10080@caradoc.them.org> References: <20090201231819.A9FB61C7A19@localhost> <20090201233251.GA27142@caradoc.them.org> <20090202042459.GA10080@caradoc.them.org> Date: Mon, 02 Feb 2009 20:03: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/msg00022.txt.bz2 On Sun, Feb 1, 2009 at 8:24 PM, Daniel Jacobowitz wrote: > On Sun, Feb 01, 2009 at 03:38:04PM -0800, Doug Evans wrote: >> I haven't looked into siginfo, but can gdb look at the insn? [akin to >> displaced stepping handling] > > I suppose, but I don't really see a point. Apologies, it's not clear what point you're referring to. I guess the issue is whether int3's in programs are supported by gdb, and by supported I mean users can rely on gdb flagging a SIGTRAP when they're executed. As you say, there are people who take advantage of this for hardwired breakpoints. There are various situations where gdb itself will singlestep code (e.g., "step", "next", s/w watchpoints). Can users expect to see the SIGTRAP in these situations (and all others)? And if the program is being run by a script, can the script expect to see the SIGTRAP in all cases?