This is the mail archive of the
mailing list for the GDB project.
Re: debugging a program that uses SIGTRAP
On Tue, 2007-03-20 at 20:34 -0600, Michael FIG wrote:
> Thanks for the swift reply!
> Daniel Jacobowitz <email@example.com> writes:
> > 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.
> 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.
> If it does seem reasonable, I can look into creating a patch. I
> haven't gotten my hands dirty in GDB before. :)
Michael, rather than telling gdb to always pass SIGTRAP
(handle SIGTRAP pass), or modifying gdb, you might be able
to debug at least a simple case (say, where there are only
a few non-breakpoint traps) by explicitly telling gdb to
pass the SIGTRAP on a case by case basis:
Program received signal SIGTRAP, Trace/breakpoint trap.
(gdb) signal SIGTRAP
Continuing with signal SIGTRAP.
If you expect a lot of events, there is a little-known
feature called a hook. You can put a hook on the "stop"
event, and have it do something to recognize your events.
Perhaps you can maintain your own list of locations.
(gdb) define hook-stop
> if in-my-list
> signal SIGTRAP