This is the mail archive of the gdb@sourceware.cygnus.com 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]

Re: signals at breakpoints in Linux



> > I'm trying to build a minimal debugger under Linux that maintains a set of
> > breakpoints and prints out some information each time a breakpoint is hit.
> > It works fine, except for the case where the child process executes a
> > breakpoint instruction and wait(2) tells me that a (non-SIGTRAP) signal is
> > pending. I can't seem to handle this case correctly, no matter what i try.
> > What is the correct course of action when a breakpoint and signal are
> > encountered simultaneously? I've tried looking at the sources for GDB, but
> > they're pretty tough to wade through.
> 
> I'm not positive about this, but I think you're misunderstanding the
> results from ptrace.  Not that they're wonderfully clear to begin
> with.
> 
> The result from wait tells you why the program stopped.  As I
> understand it, it either stopped because of a breakpoint, or it
> stopped because of a signal --- it can't stop for both reasons.

Ah-hah! Using this tip, it was a 5-second fix to stop interpreting wait
results as breakpoints simply because they happened to fire exactly at
breakpoints. Now i interpret the results of wait as a breakpoint iff the
child lands on a breakpoint AND wait passes me a SIGTRAP.  That works like
a charm. Duh. :-)  I figured there was a simple consistency somewhere in
there.

Thanks!
neal


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