This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: debugging a program that uses SIGTRAP
> 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