This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: What's with all the Cisco stuff?


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

Stan> Going by your description, this seems very heavyweight, only
Stan> really appropriate for Unix-sized OSes.  But I'm not that
Stan> familiar with SNMP; what should I look at to educate myself?

SNMPv1 is described in RFCs 1155, 1157, and 1213.  Although in this
case, a summary is probably more valuable than the specification. I
re-read Chapter 25 of Stevens' _TCP Illustrated, Volume I_ as I was
thinking about the similarities between SNMP and KOD.

I think it's fair to characterize SNMP as heavyweight implementation
of simple concepts.  And those concepts seem to fit the requirements
of a KOD system fairly well.

        * A mechanism for uniquely identifying objects.
       
        * A mechanism for describing the type of an object,
          constructing aggregate types out of simple types.

                SNMP's base types are INTEGER, OCTET STRING, Counter,
                Gauge, etc.  KOD would require types like unsigned 32
                bit integer, IEEE double precision float, etc.

        * A mechanism for constructing vector/tables from dynamic 
          data structures (lists, trees, etc.)

        * A mechanism for fetching objects

        * A mechanism for representing everything on the wire.

Unlike SNMP, where the MIB definition is known by both the agent and
the network management station, KOD has a additional requirement of:

        * A mechanism for obtaining the list of kernel objects from
          the target.

jtc> Even though I walked through the above thought experiment,
jtc> I'm still not convinced that direct access to kernel data
jtc> structures with GDB scripts is not superior.

Stan> You're assuming that direct access is possible though.  While
Stan> some, like VxWorks, give you full access to things like task
Stan> state, others, like QNX, don't seem to keep kernel data in a
Stan> place where you can get to it.

I don't think I'm making any such assumption, but I guess it depends
on how you define 'kernel'.  In systems like QNX, a lot of what might
be considered kernel services are implemented by user level processes.
In my definition of kernel, only the microkernel itself is the kernel
and only it has kernel objects.  The rest is application space, and
can be debugged like any other multi-process application.  If the
definition of kernel is extended to contain the process manager and
various resource managers/device drivers, I can see the problems as
the debug agent has to cross process boundries.

Stan> It's also easy to imagine an RTOS that got stopped right in the
Stan> middle of updating a kernel object; wouldn't you rather have the
Stan> RTOS report "invalid, please step to <x>" instead of being
Stan> misled by pointers and references that don't connect right?

This is going to be hard to handle in any case.  I find it hard to
believe that any RTOS is going to make concessions for the case where
the kernel is interrupted while objects are being updated.  How is the
debug agent going to know this is true, and what value is it going to
substitute?

Stan> Yes, which is why a display-only ability is a good intermediate
Stan> step.  GDB often doesn't make values out of the data it
Stan> displays, for instance the output of "x" is just output, you
Stan> don't get an array of values.  But I think that everybody still
Stan> finds "x" to be a useful command.

Yes, but there is alternatives to "x" when you need to manipulate a
memory value in a GDB expression.  Casting an address to a type and
dereferencing it may be a bit ugly, but it works.  Likewise for info
registers it outputs a pretty list of registers, but you can use $pc,
$sp, etc. convienence variables in expressions.

A kernel object system without the ability to use those values in
expressions seems vary limited to me.  Perhaps this is just my bias,
scripting is an integral part of the debugging experience/process to
me.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]