This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: What's with all the Cisco stuff?
- To: jtc@redback.com
- Subject: Re: What's with all the Cisco stuff?
- From: Stan Shebs <shebs@cygnus.com>
- Date: Mon, 16 Aug 1999 18:40:16 -0700
- CC: gatliff@haulpak.com, gdb@sourceware.cygnus.com
From: jtc@redback.com (J.T. Conklin)
Date: 16 Aug 1999 13:23:56 -0700
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).
Put the emphasis on *should*. Of course the target should return back
exact data types, so as to distinguish between integer and string
types, but it ought to return "hints" also, for instance that a
numeric value should be displayed in hex, while another value should
be displayed in decimal. The user can always override.
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.
Going by your description, this seems very heavyweight, only really
appropriate for Unix-sized OSes. But I'm not that familiar with SNMP;
what should I look at to educate myself?
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.
You're assuming that direct access is possible though. While some,
like VxWorks, give you full access to things like task state, others,
like QNX, don't seem to keep kernel data in a place where you can
get to it. It's also easy to imagine an RTOS that got stopped right
in the middle of updating a kernel object; wouldn't you rather have
the RTOS report "invalid, please step to <x>" instead of being misled
by pointers and references that don't connect right?
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.
Yes, which is why a display-only ability is a good intermediate step.
GDB often doesn't make values out of the data it displays, for instance
the output of "x" is just output, you don't get an array of values.
But I think that everybody still finds "x" to be a useful command.
Stan