From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32575 invoked by alias); 21 Mar 2007 14:14:40 -0000 Received: (qmail 32566 invoked by uid 22791); 21 Mar 2007 14:14:39 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 Mar 2007 14:14:33 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 4EB7A48CDB1; Wed, 21 Mar 2007 10:14:31 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18014-02-7; Wed, 21 Mar 2007 10:14:31 -0400 (EDT) Received: from joel.gnat.com (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 30CE148CBF5; Wed, 21 Mar 2007 10:14:29 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 13206E7B39; Wed, 21 Mar 2007 07:15:23 -0700 (PDT) Date: Wed, 21 Mar 2007 14:14:00 -0000 From: Joel Brobecker To: Michael FIG Cc: gdb@sourceware.org Subject: Re: debugging a program that uses SIGTRAP Message-ID: <20070321141522.GF21799@adacore.com> References: <7qy7lruz89.fsf@babe.fig.org> <20070321021809.GA2523@caradoc.them.org> <7qtzwfuxxk.fsf@babe.fig.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7qtzwfuxxk.fsf@babe.fig.org> User-Agent: Mutt/1.4.2.2i 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: 2007-03/txt/msg00252.txt.bz2 > Okay. I thought somehow GDB would pass SIGTRAP iff it knows it has > not set a breakpoint on the current instruction pointer by scanning > its list of breakpoints. > > > Even if you get past that point, your handler will now get called > > every time GDB hits a breakpoint or single steps - single stepping > > will probably be broken. > > Would the above suggestion be reasonable? I think it would behave > nicer than what I have now, especially for my circumstance, since > there isn't any overlap between the code I'm trying to debug and the > code _it's_ trying to debug. As Daniel said, this is one of the trickiest parts of GDB. At first glance, I think your suggestion above will not work, because of single stepping. Each single-step operation ends with a SIGTRAP at the location where the single-step finished, and chances are you have no breakpoint at that location. This SIGTRAP is not to be passed back to the inferior. You may think of adding some extra logic that guesses whether the SIGTRAP comes from your single-step or from another source, but I think the logic will be very fragile. Normally, all you are guarantied is that the program will stop once it gets outside a given code range. But in fact, in can stop anytime, even when inside that range. Try "set debug infrun 1" and then do a few single steps; have a look at the output on x86-linux. The way to achieve what you are suggesting, I think, is to use "software single-step", which means single-stepping achieved by way of breakpoints rather than using the kernel single-step. I don't think this is implemented on x86, however. Sorry, but I think you're pretty much stuck in your case. Can you not use anything other than SIGTRAP? -- Joel