This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Temporary breakpoints
- To: Kevin Buettner <kevinb@cygnus.com>
- Subject: Re: Temporary breakpoints
- From: Jim Blandy <jimb@cygnus.com>
- Date: 16 Aug 1999 01:49:53 -0500
- Cc: gdb@sourceware.cygnus.com
- References: <199908120252.TAA25463@elmo.cygnus.com>
> 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.
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.
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.