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



   Date: Tue, 23 Nov 1999 19:34:19 -0500
   From: Mark Salter <msalter@cygnus.com>

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

Theoretically, yes.  But if you have to do a lot of accesses in order
to accomplish a computation, packet traffic will be really bad.  And
you're still replicating the OS' algorithms in GDB scripts, which
seems like a really bad idea; just because it's a script doesn't mean
it won't be a maintenance problem.  A minor user-invisible change to
RTOS internals, and the script stops working.  I really don't want to
be getting those kind of bug reports.

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

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

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

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.

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

Which means that each GUI now has to have its own version of the same
thread-groveling script?  Sounds like an MxN problem.  GDB is supposed
to be a toolbox for debugging; it's silly to get rid of all the useful
tools, and say "here are some blocks of iron and wood, you can use
these to build everything else you might need".

(Lest anybody be misled, I believe that one of the requirements for
the scripting language *should* be that it can implement parts of a
libgdb API.  That is, one can write scripts that create and manipulate
the objects that the API would make available to the library's
clients, such as breakpoints and threads.)

   > 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 current round of GDB internal changes took four years from
proposal to implementation.  I'm not that optimistic about improved
scripting being available soon.  In the meantime, people are using
proprietary debuggers instead of GDB, in part because those debuggers
include the specific RTOS support that we're being reluctant to add.
To quote RMS, commenting in the GCC manual on GCC's architecture:
"Elegance, theoretical power and simplicity are only secondary."

   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.

You make some very good points here; but I'm not talking about
*requiring* OS support to get extra thread info.  I'm proposing an
optional capability that is available for any system that wants to use
it.  Also note that GDB's remote protocol already requires the target
OS to supply basic thread info via specialized packets; the protocol
has worked this way for some years, and so far everybody seems to be
OK with that.  All I'm talking about is adding another degree of
extensibility to the existing system.

								Stan


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