> 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
|
