Re: Extra Thread Info

[Stan Shebs <shebs at cygnus dot com>]

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

   I didn't think of these as flaws, as I was thinking along the lines
   that any info gathering mechanism had to be built on top the existing
   target primitives, otherwise it would be limited to a small subset of
   targets.  That is what I would consider a fatal flaw.

   And if you compare the difficulty of implementing data structure
   groveling code in GDB's C code vs. doing the same in a GDB script, 
   I think the choice is clear.  

I think there's some confusion here.  The extra thread info I'm
referring to is already being collected by a special type of packet in
the standard protocol.  As far as I know only eCos uses that packet,
but since it's been in the sources for a year, it's possible that some
other OS is using it too.  The display of the info is also already
written, but it's only in the version of the sources that you can
download along with eCos.  It does nothing more than printf three
additional strings that were received in the special thread packet -
and one of those strings is always empty these days.

So neither the regular nor the eCos GDB do any groveling of data
structures, nor am I proposing such an addition.  What I'm proposing
is to create an abstract notion of additional thread info, and to
regularize its handling, so that if it's appropriate for the target OS
to do the dirty work itself, it can, and then GDB simply passes the
data through for the user to see.

   The point is a target is going to have to expose *some* method of
   obtaining the thread list.  It may be the symbols that make up the
   list, it may be a function that when called fills in a buffer, etc.
   If the vendor makes the thread list available at all, there has to
   be some mechanism of obtaining it.  If they don't, a stub will not
   be able to obtain the same information for a remote protocol 
   extension either.

If the stub is part of the OS, then it has the ability to collect
thread info.  In fact, a thread-supporting stub already has to be
able to get basic thread info, so it already has a way to collect
threads and report them.

This is just another example of putting functionality in the stub for
the sake of consistency and performance.  It's not really any
different from having stubs manage breakpoints, watchpoints, searches,
or any of the other stub-complicating performance-enhancing changes
that have been proposed in the past.  I think this one "feels"
different in that it addresses higher levels of functionality, but as
I've mentioned in a previous message, users want more functionality
and more OS support in the debugger, not less.

								Stan