This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Extra Thread Info



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

   I believe supporting extra thread info is a difficult problem because,
   in general, there are an open ended number and set of types of thread
   variables.  These may be known for a given native config, but embedded
   configs demand a more general approach.

   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?

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

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.

An additional non-fatal objection is that GDB's scripting machinery is
too weak to depend on as an integral part of the debugger.  It's good
enough for people to develop scripts for use inhouse, but imagine
trying to manage and distribute dozens of configuration-specific
script files; it would be a disaster.  That's a good argument for a
more powerful scripting language, but nobody's working on one, so we
can't count on it being available soon enough to matter.

								Stan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]