This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: signals at breakpoints in Linux
- To: Jim Blandy <jimb@cygnus.com>
- Subject: Re: signals at breakpoints in Linux
- From: Neal Cardwell <cardwell@cs.washington.edu>
- Date: Wed, 28 Jul 1999 00:29:30 -0700 (PDT)
- cc: gdb@sourceware.cygnus.com
> > 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