Re: What's with all the Cisco stuff?

[William Gatliff <gatliff@haulpak.com>]

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

I agree completely-- keeping a "thin" stub is definitely the way to go.

In retrospect, what I'm after may be something less related to what you
guys are talking about than I thought...  If I'm trying to make gdb
"aware" of an RTOS like uC/OS or eCos, for which I have sources, then the
kernel data structures should exist as symbols, so I should be able to
peek/poke at them with regular gdb functionality when the target stops.

OTOH, the threading stuff needs more OS support that's best handled in
the stub (at least for runtime performance reasons): the stub can use
whatever kernel calls are available to check the active thread when a
TRAP occurs, and keep going when it's the wrong one.  This doesn't
require any gdb support at all, except that  the continue is hard to do
if gdb has already clobberred the original opcode with the breakpoint
isn...

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems