Re: Temporary breakpoints

[Kevin Buettner <kevinb@cygnus.com>]

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