Re: What's with all the Cisco stuff?

[Stan Shebs <shebs@cygnus.com>]

   From: jtc@redback.com (J.T. Conklin)
   Date: 12 Aug 1999 14:42:57 -0700

   The current implementation suffers from an even greater drawback ---
   It needs a 'live' system to work.  If the OS may doesn't allow you to
   access kernel structures, let's solve that problem, as there may be a
   need to access kernel structures in a less processed manner.  If the
   representation of kernel objects changes, you're would have to change
   the KOD code in the debug agent (stub), which is pretty much the same
   as changing code in a gdb script.

My view is that there are several levels of capability, depending on
object type and OS type.  If an object is virtual and needs to be
constructed by the OS, then with corefiles you just lose, just as you
do with inferior function calls.  On the other hand, the object
construction algorithm may be expressible as a script, and the target
memory from which to construct the object is available, in which case
GDB doesn't need to get the kernel involved.  On the third hand, the
algorithm may be too tricky or slow for GDB's scripting abilities,
which means more adding a powerful scripting language or writing in C
somewhere.

   If for some reason there is a need for KOD outside of gdb's scripting
   ability, it needs to include the experience of a larger pool of
   embedded systems users.  

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.

I'm not at all wedded to doing KOD in C code in GDB; there are plenty
of alternatives.  However, it's very important that we provide it in
some form, and that users can get to it easily.

								Stan