Re: Extra Thread Info

[Stan Shebs <shebs at cygnus dot com>]

   From: jtc@redback.com (J.T. Conklin)
   Date: 30 Nov 1999 15:53:38 -0800

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

This is misleading, because GDB's basic thread control has to be part
of the target vector today.  Because remote-sim.c is missing
implementations of the key methods, GDB cannot do even basic thread
debugging with any of the builtin simulators, even if the simulator is
executing a thread-supporting OS.  That's not to say that it couldn't
be done, but it would involve some decisions and some hacking.  For
instance, suppose you want to model a multiprocessor with a builtin
sim, and have each processor appear to be a thread.  That could be
made to work.  Now suppose you want to run a thread-supporting OS on
your simulated multi-processor - should remote-sim.c report the
processor "threads" or the OS threads.  You may even want to switch
back and forth!  Whatever your choice, GDB must know all about how to
start and stop each kind of thread, and how to display the list of
threads.

So as long as GDB supports basic thread debugging, it will have
to have some knowledge of the OS implementing the threads.

In any case, GDB does have all kinds of OS-specific knowledge for
native OSes - what makes them so different?  Indeed, native GDB has to
have a whole separate set of code to access basic thread info in
corefiles, because it can't make ptrace/ttrace calls then.

   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.

Nobody is stopping you from using only primitives for your work.  But
you're saying that everybody should be made to use primitives, and
that they must design their OS to accommodate that usage, whether or
not it's reasonable for them.  We're supposed to be adapting the
debugger to meet the needs of the users, not forcing the users to
conform to our preconceptions about how the debugger should be
structured internally.

								Stan