Re: debugging a program that uses SIGTRAP

[Michael Snyder <Michael dot Snyder at palmsource dot com>]

On Tue, 2007-03-20 at 20:34 -0600, Michael FIG wrote:
> Thanks for the swift reply!
> 
> Daniel Jacobowitz <drow@false.org> 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
      > end
    > end