Temporary breakpoints

Kevin Buettner kevinb@cygnus.com
Mon Aug 16 09:00:00 GMT 1999

Jim Blandy wrote:

> > I have a question regarding temporary breakpoints...
> >
> > Under what circumstances should a temporary breakpoint be deleted?
> It should be deleted under the same circumstances in which GDB tells
> the user it has been hit.  A temporary breakpoint is a user-visible
> construct (unlike many breakpoints in GDB), so its behavior must be
> consistent from the user's point of view.

This is a sensible position to take and I think I am starting to favor
this point of view.

When I was in Sunnyvale last week, Jim Ingham made a convincing
argument for leaving the temporary breakpoint intact.  His argument
goes like this...  when you have a fairly complicated GDB session with
a number of breakpoints, you're likely to forget where all of your
breakpoints are.  When you enter a bit of code through some other
pathway that causes you as the user of the debugger to start single
stepping, you may well forget that you're about to step onto one of
your temporary breakpoints.  If you step over it and it gets deleted,
the harm caused by deleting this breakpoint is greater than leaving it
in (assuming of course that you want it left in).  I.e, there's very
little harm incurred by leaving it in and then hitting it (as a result
of continuing) at some later point.

Rereading the above, I don't think I was able to do justice to Jim's
argument.  Jim, if you're reading this, you may want to reply with a
more cogently worded version...

> GDB does not report a breakpoint hit if it occurs exactly when GDB
> would have stopped stepping anyway.  So, if you set a breakpoint on
> the first instruction of a line, and "step" to it, GDB won't report a
> hit, because it would have stopped there anyway.  If you set a
> breakpoint on an instruction in the middle of the line, GDB will
> report it, because you've stopped in an unusual place.  But if you
> stepi, then GDB will never report a breakpoint hit.

At the present time, the behavior of gdb with regard to reporting that
a breakpoint has been hit due to single stepping depends on the platform
on which you are running gdb:

    Linux/x86 does not report that the breakpoint has been hit.

    Solaris/sparc does report that the breakpoint has been hit.

I haven't tried other platforms (yet), but I suspect that the behavior
will depend upon whether or not a single step is implemented via
breakpoints or in hardware.  (If it's implemented in hardware, you won't
see the message.)

I think the breakpoint should be reported hit regardless of whether
you're single stepping or not (and regardless of the implementation).
If we're going to delete temporary breakpoints when they're hit due
to single stepping, this is particularly important so that the user
can re-set the temporary breakpoint if it's important to him.

> It's worth noting that a breakpoint's behavior depends on its intended
> use.  Breakpoints which GDB uses to implement some internal feature
> should behave differently from user-level breakpoints.  For example,
> the breakpoint which GDB uses to tell when a new shared library has
> been loaded should be considered "hit" even if you reach it via stepi,
> or even if the user has set another breakpoint on top of it ---
> otherwise, GDB will miss the event it was waiting for.
> This is what that hairy, worthless table in bpstat_what is all about.
> Note that the whole table could be replaced by a call to `max' and a
> little logic, if someone wants to take the time.


More information about the Gdb mailing list