This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: debugging a program that uses SIGTRAP


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.
> (gdb)
> 
> 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
broken.

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.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]