Re: What's with all the Cisco stuff?

[jtc@redback.com (J.T. Conklin)]

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