Re: Extra Thread Info

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan> I'm not too concerned about simulators, because I haven't
Stan> personally seen or heard of any simulators that had an OS
Stan> implicitly buried in them, such that remote-sim.c had to
Stan> implement thread methods itself - certainly there are none such
Stan> in GNU right now.  The whole idea involves so many variables
Stan> that I'd want to hear about the architecture of a real example,
Stan> before trying to design GDB to accommodate it.

That's just the point.  

A simulator (or ICE) environment is a blank slate --- just like a
random piece of target hardware.  It might run eCos, RTEMS, vxWorks,
IOS, etc.  It does not (and IMO it should not) have any knowlege of
the OS running on it.  

Ideally the same generic embedded GDB should be able to debug all of
these OSs.  But instead of going through an intermediary debug agent,
GDB (or an ICE under GDB's control) can examine and manipulate the
targets memory and registers directly.  Thus it seems wrong to put OS
specific knowledge in the simulator's target vector.  It should be at
a higher level so that it can use the primitives provided by every 
target.

The same issues are found in examining crash dumps.

        --jtc

-- 
J.T. Conklin
RedBack Networks