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: gatliff@haulpak.com
- Subject: Re: What's with all the Cisco stuff?
- From: Stan Shebs <shebs@cygnus.com>
- Date: Fri, 13 Aug 1999 15:08:28 -0700
- CC: gdb@sourceware.cygnus.com
Date: Fri, 13 Aug 1999 08:13:33 -0500
From: William Gatliff <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.
On the embedded side, could RTOS support be made a stub issue, instead of a
gdb issue? As an embedded developer, I find it much easier to add/modify a
stub than to muck around with the internals of gdb itself.
If there were a standard set of RDP messages that could be used to deliver
OS information from a stub back to gdb, then I would be happy to add stub
support for my own RTOS, whatever that happens to be, using the RTOS's
native calls.
That was kicked around a bit in our internal (ahem :-) ) discussion.
Basically you ask the RTOS "what kinda objects you got?", get back a list
of types, then ask "how should type X be displayed?" and get back
something like a printf format string or maybe even a bit of XML,
then GDB follows instructions when getting the objects' data and
displaying it.
eCos and other folks observed that this was probably too heavyweight
to impose on every RTOS, although it would make sense for the larger
OSes. Also, you still have the dumpfile problem that JT alluded to,
where you don't necessarily have a live target to run a stub. So
while it would be preferable to put OS-specific bits on the target
side, the design needs to accommodate the possibility that all the
IQ is living on the host somewhere.
Stan