Re: Temporary breakpoints

[Bill Mann <wmann@avici.com>]

At 01:49 AM 8/16/99 -0500, 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.

Right!

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

But I think that's not the way it should work.  If I set a breakpoint, then
step over it, I want the breakpoint to be hit.  I want it to print what it
would normally print, or count if it's a multiple proceed, or execute
special commands if they are defined.  I see a breakpoint as a temporary
patch to my program, and I want single step to honor that patch (as a unit).

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

But what's different about internal breakpoints?  All breakpoints should
work like this.  If there are several breakpoints at the same location,
they should all be executed, one after the other, but only return
interactive control to the user if one or more of them don't 'continue'.

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