Re: Extra Thread Info

[Stan Shebs <shebs at cygnus dot com>]

   Date: Sun, 28 Nov 1999 13:54:42 -0500
   From: Mark Salter <msalter@cygnus.com>

   > Perhaps the eCos developers' judgment is flawed, but they certainly
   > preferred adding a packet over the alternative of encoding eCos
   > internals into GDB, whether it was as scripts or C code.

   I wouldn't say their judgement is flawed. I would agree with their
   decision if debugging using the remote protocol were the only 
   debugging environment to be considered. But you erect a strawman, here.
   I never suggested encoding eCos (or any other) OS internals in gdb.

If the info is encoded in a script that always ships with GDB, then
from my point of view, it's part of GDB.  Sometimes it's unavoidable;
GDB sources include all kinds of gory detail about AIX, HP-UX, etc,
some of which was acquired by reverse engineering and experimentation.
But we only want to do that if absolutely necessary; if there is a
defined API or protocol, we would much rather use that instead.

     But this
   > decision was made a couple years ago; I'll bring it up with them
   > again, perhaps they've changed their minds about this point.

   I wasn't aware that the eCos group was the sole arbiter of this issue.

Of course not!  I'm the sole arbiter. :-) But as an open-source RTOS
that uses GDB as its primary debugger, eCos is an important client,
and it's worth considering how best to accommodate it, and how that
used to improve OS support in general.

   > It's certainly always possible to write something that works for a
   > particular situation.  My concern is that we're supposed to be
   > supplying something that works consistently for users across both GDB
   > and OS revs.

   GDB shouldn't have to worry about OS revs. I'm assuming that the script
   to extract thread info from a target is provided and maintained by the
   OS vendor, not the gdb maintainers.

So each vendor provides a script with a different name, and it has to
also get a different name whenever the OS changes, and the user has to
know which script to use.  Seems less desirable than an "info threads"
or "info extra" that has the same usage for everybody.

   >    A gui can do what a gdb script does and use memory read operations
   >    to get the info it needs.

   > Which means that each GUI now has to have its own version of the same
   > thread-groveling script?  Sounds like an MxN problem.

   No, the OS vendor-supplied thread-groveling scripts provide an interface
   to thread info that can be used from a CLUI or from a GUI.

How is the GUI to collect the script's output though?  By parsing it?
If so, then you have to specify the output format of scripts written
by random third parties, not to mention writing the parser.  This is
getting to be an awful lot of work just to avoid adding ~20 lines to
GDB.  Certainly if somebody wants to provide all-singing all-dancing
OS support, they'll have to do that anyway, but that's OK; I just want
GDB to provide a very basic level of thread info support that lets
people use it without a lot of work, and that does not preclude adding
something more elaborate later on.

   This solution by definition, only works if you are using the remote
   protocol. It does not address gdb's debugging interface to simulators.
   This is a huge deficiency in my opinion.

Implementationwise I was going to add a target vector entry per the
usual process; the concept of extra thread info is not specific to the
remote protocol.  Then we can do extra thread info for Win32 if
desired, etc.

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

								Stan