This is the mail archive of the
mailing list for the GDB project.
Re: debugging a program that uses SIGTRAP
- From: Daniel Jacobowitz <drow at false dot org>
- To: Michael FIG <michael-dated-1177034790 dot 7f6941 at fig dot org>
- Cc: gdb at sourceware dot org
- Date: Tue, 20 Mar 2007 22:18:09 -0400
- Subject: Re: debugging a program that uses SIGTRAP
- References: <email@example.com>
On Tue, Mar 20, 2007 at 08:06:30PM -0600, Michael FIG wrote:
> Hi, all...
> How do you folks debug GDB under GDB?
It's quite easy. GDB never generates SIGTRAPs in itself, only in the
program it is debugging. The outer GDB is only looking at the inner
GDB, not at the program the inner GDB is controlling.
> However, when I change the handling of SIGTRAP to do this
> automatically, my program dies:
> (gdb) handle SIGTRAP pass
> SIGTRAP is used by the debugger.
> Are you sure you want to change it? (y or n) y
> Signal Stop Print Pass to program Description
> SIGTRAP Yes Yes Yes Trace/breakpoint trap
> (gdb) r
> Starting program: /fig/home/michael/sw/libstackless/t
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.
> The program is attached below.
When you do this, it's not just resending SIGTRAPs that it would
display, but also all the internal ones. In this particular case it's
probably something from the shared library initialization breakpoint,
before main and before you have a SIGTRAP handler. 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
I don't see any good way to solve this. You've got two sets of
breakpoints and they're both going to stop GDB - it doesn't know which
ones you want and which you don't.