Re: Extra Thread Info

[Mark Salter <msalter@cygnus.com>]

>>>>> Stan Shebs writes:

>    From: jtc@redback.com (J.T. Conklin)
>    Date: 23 Nov 1999 13:31:54 -0800

>    Besides your three suggestions, I prefer a fourth: provide target
>    specific user defined functions which traverse the thread table and
>    presents the information in a useful format.  This doesn't bind any
>    knowledge about any particular thread implementation into GDB; is
>    easily modifyable by the end user (rather than a GDB hacker) to add,
>    remove, or change the presentation of thread information; and should
>    not require any changes to the target.

> I didn't mention this option because it has a couple fatal flaws.
> First, it doesn't work if the OS doesn't have a thread table.  What if
> the OS calculates it on the fly, or expects the programmer to choose
> the location of the table or whatever structure it is?

I wouldn't think this is much of a problem. What if the OS calculates its
thread list on the fly? Presumably, a programmer has to write the code
that does this on the fly calculation. If you can do it in a programming
language, you should be able to do it in gdb's scripting language.

> Second, it requires a set of symbols.  In your VxWorks example, you
> manage to have WIND_TCB and activeQHead.pFirstNode available somehow.
> I can't justify requiring an OS to expose its private data structures,
> nor requiring users to link the definitions of the data structures
> into their applications, whether or not the application uses those
> structures directly.  (There is also a potential usability problem
> with getting the compiler to include unused symbols in an executable.)

You can't justify requiring an OS to export symbols, yet you could justify
requiring an OS to add an interface to support the remote protocol
thread packets. The major advantage to exporting symbols is that it
does not change the memory footprint of an OS/application. This is often
critical when chasing bugs. At worst, an OS could export symbols from
key modules. Its not necessary to have symbols for everything. I've
written scripts to get thread info which relied only on a single
symbol being exported (a pointer to the head of the thread list).

> Third, there's no internal pathway for GUI clients to get the
> information and do their own thing with it.  In other words, scripts
> cannot presently be used to implement any part of a libgdb API.

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

> An additional non-fatal objection is that GDB's scripting machinery is
> too weak to depend on as an integral part of the debugger.

Let's get rid of the weaknesses :-)

The major flaw that I see with requiring OS support to get thread info
is that it requires target code to run. If you are running in a 
simulation environment, then you end up in the awkward position of
having to run the simulator to get information about the system being
simulated. Another disadvantage is that you can't extract thread
information from a dumped core file for those systems able to
generate one.


--Mark