Re: Temporary breakpoints

Re: Temporary breakpoints

[Bill Mann]

Seems to me that single stepping over any breakpoint should have the effect
of hitting the breakpoint, that is, counting counters, executing special
gdb commands, etc., and removing temporary breakpoints.  Single step is a
'go slow' mode, not a 'do something different' mode.

So stopping at a breakpoint should skip the normal singlestep action.  When
hitting a breakpoint which does an automatic continue, the singlestep
action should happen in place of continuing.  Same applies to watchpoints.

At 07:52 PM 8/11/99 -0700, Kevin Buettner wrote:
>Hi all,
>
>I have a question regarding temporary breakpoints...
>
>Under what circumstances should a temporary breakpoint be deleted?
>
>Sounds like a silly question, right?  Obviously, it should be deleted
>when the breakpoint is hit (provided that any conditions attached to
>the breakpoint are met).  But what constitutes hitting a breakpoint? 
>
>Clearly, running the program or continuing may cause execution to stop
>due to the breakpoint.  But what about single stepping (either step or
>next)?
>
>E.g, suppose the debugger is stopped several instructions (or
>statements) prior to the address at which you place a temporary
>breakpoint.  What should happen when you single step over the
>address/statement on which the temporary breakpoint is placed?  Should
>the breakpoint be deleted?  Or should it remain in effect until it is
>hit in some fashion that's not due to single stepping?
>
>All recent versions of gdb that I've tried on Linux/x86 will not
>remove the temporary breakpoint when you step over the temporary
>breakpoint.  OTOH, Solaris does the opposite.  On Solaris, GDB will
>remove the breakpoint when stepping over a temporary breakpoint.  I
>spoke with Stan about this briefly and we agreed that the reason for
>this difference in behavior has to do with the fact that the SPARC
>architecture doesn't have a hardware single-step, whereas the x86
>architecture does.
>
>Due to this inconsistency in behavior, I conclude that GDB will most
>likely require some fixing, but I'd like to determine what the desired
>behavior should be prior to fixing it.
>
>I have looked at the GDB manual, but, to me at least, there is some
>ambiguity about what the expected behavior should be.  In particular,
>under "Setting breakpoints", it says the following:
>
>    tbreak args 
>	Set a breakpoint enabled only for one stop.  args are the same
>	as for the break command, and the breakpoint is set in the
>	same way, but the breakpoint is automatically deleted after
>	the first time your program stops there.  See Disabling
>	breakpoints.
>
>Under "Disabling breakpoints", the GDB manual says:
>
>    A breakpoint or watchpoint can have any of four different states
>    of enablement: 
>
>	[ Descriptions of 'Enabled', 'Disabled', and 'Enabled once' elided ]
>
>	* Enabled for deletion 
>	  The breakpoint stops your program, but immediately after it
>	  does so it is deleted permanently.
>
>
>One could argue that on linux, the program is stopped due to the
>hardware single step and not the breakpoint getting hit, so it's
>behavior is correct.  But you can make a similar argument for
>Solaris which doesn't have hardware single stepping.  I think it'd
>be more useful if gdb behaved in a consistent manner regardless of
>whether the architecture supports hardware single stepping.
>
>Opinions?
>
>Kevin

Re: Temporary breakpoints

[William Gatliff]

Jim Blandy wrote:

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

Couldn't have said it better myself. :^)

b.g.


--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems

Re: Temporary breakpoints

[Kevin Buettner]

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.

Kevin
From jtc@redback.com Mon Aug 16 13:27:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Stan Shebs <shebs@cygnus.com>
Cc: gatliff@haulpak.com, gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Mon, 16 Aug 1999 13:27:00 -0000
Message-id: <5mn1vriieb.fsf@jtc.redbacknetworks.com>
References: <199908132208.PAA19753@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00178.html
Content-length: 3374

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

Stan>    Date: Fri, 13 Aug 1999 08:13:33 -0500 From: William Gatliff
Stan>    <gatliff@haulpak.com>

>> I would ecstatic with more interest and input here.  "RTOS support"
>> is an area where GDB gets hammered relative to its competition, and
>> display of kernel objects is a specific feature that gets comes up
>> frequently.

Stan>    On the embedded side, could RTOS support be made a stub
Stan>    issue, instead of a gdb issue?  As an embedded developer, I
Stan>    find it much easier to add/modify a stub than to muck around
Stan>    with the internals of gdb itself.

Stan>    If there were a standard set of RDP messages that could be
Stan>    used to deliver OS information from a stub back to gdb, then
Stan>    I would be happy to add stub support for my own RTOS,
Stan>    whatever that happens to be, using the RTOS's native calls.

Stan> That was kicked around a bit in our internal (ahem :-) )
Stan> discussion.  Basically you ask the RTOS "what kinda objects you
Stan> got?", get back a list of types, then ask "how should type X be
Stan> displayed?" and get back something like a printf format string
Stan> or maybe even a bit of XML, then GDB follows instructions when
Stan> getting the objects' data and displaying it.

The "how should type X be displayed?" question IMO is inappropriate.
The target knows the kernel objects and their types, but the user is
in a better position to know how they are to be displayed (or other-
wise manipulated).

I've thought about this a bit, and it seems the best model to use is
something like SNMP.  But instead of a pre-defined MIB that is known
by both the debug agent on the target and GDB, the MIB is downloaded
from the target.  There should probably be traps so the debug agent
can tell GDB that new MIBs are present or old ones have been removed
if the kernel has loadable kernel modules or the like.

A `kod' command would take the name of an object to fetch, returning a
value that could be used in other GDB expressions.  

        set $threads = kod system.threads
        if ($maxthreads < $threads)
                set $maxthreads = $threads
        end

Perhaps an incompletely specified MIB entry would return a vector
containing the values in the entire MIB hierarchy?

With SNMPv1-like get & get-next requests, extracting tables would be
nearly as inefficent as GDB scripts that grovel through memory.  I'm
not familiar with the SNMPv2 get-bulk request, but from what's been
described to me, something like that could be used to improve
performance.

Stan> eCos and other folks observed that this was probably too
Stan> heavyweight to impose on every RTOS, although it would make
Stan> sense for the larger OSes.  

Even though I walked through the above thought experiment, I'm still
not convinced that direct access to kernel data structures with GDB
scripts is not superior.  In my opinion, KOD must be much more than a
kernel object pretty-printer to justify its exisistance.  Individual
objects must be able to be queried and their values must be usable in
GDB expressions.

This model requires quite a bit of hair to create an abstraction layer
between kernel objects and GDB.  I'm not sure that that abstraction
provides enough benefits to overcome the complexity in an OS of any
size.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From gatliff@haulpak.com Mon Aug 16 13:58:00 1999
From: William Gatliff <gatliff@haulpak.com>
To: jtc@redback.com
Cc: Stan Shebs <shebs@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Mon, 16 Aug 1999 13:58:00 -0000
Message-id: <37B87B49.268721B5@haulpak.com>
References: <199908132208.PAA19753@andros.cygnus.com> <5mn1vriieb.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00179.html
Content-length: 1275

> Stan> eCos and other folks observed that this was probably too
> Stan> heavyweight to impose on every RTOS, although it would make
> Stan> sense for the larger OSes.
>
> Even though I walked through the above thought experiment, I'm still
> not convinced that direct access to kernel data structures with GDB
> scripts is not superior.

I agree completely-- keeping a "thin" stub is definitely the way to go.

In retrospect, what I'm after may be something less related to what you
guys are talking about than I thought...  If I'm trying to make gdb
"aware" of an RTOS like uC/OS or eCos, for which I have sources, then the
kernel data structures should exist as symbols, so I should be able to
peek/poke at them with regular gdb functionality when the target stops.

OTOH, the threading stuff needs more OS support that's best handled in
the stub (at least for runtime performance reasons): the stub can use
whatever kernel calls are available to check the active thread when a
TRAP occurs, and keep going when it's the wrong one.  This doesn't
require any gdb support at all, except that  the continue is hard to do
if gdb has already clobberred the original opcode with the breakpoint
isn...

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems