Re: Extra Thread Info

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

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

Stan> I didn't mention this option because it has a couple fatal
Stan> flaws.

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.  

Stan> First, it doesn't work if the OS doesn't have a thread
Stan> table.  What if the OS calculates it on the fly, or expects the
Stan> programmer to choose the location of the table or whatever
Stan> structure it is?

If the OS computes a thread table on the fly, we should be able to do
the same in a GDB script.  It may not be pleasant do to so.

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

That's just one example of one way to do it.

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.

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

This probably needs to be addressed.  There are many current commands
--- primarily those that present target information like info reg ---
that should be scripts.  There are others where it would be useful to
call out to script `hooks'.

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

As a language, it's weak.  As an implementation, it seems pretty
solid.

Stan> It's good enough for people to develop scripts for use inhouse,
Stan> but imagine trying to manage and distribute dozens of
Stan> configuration-specific script files; it would be a disaster.

No worse than embedding target specific knowlege into GDB's C files.

        --jtc

-- 
J.T. Conklin
RedBack Networks