From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: msalter@cygnus.com Cc: jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 23 Nov 1999 17:40:00 -0000 Message-id: <199911240140.RAA25740@andros.cygnus.com> References: <199911240034.TAA11366@msalter2.cygnus.com> X-SW-Source: 1999-q4/msg00321.html Date: Tue, 23 Nov 1999 19:34:19 -0500 From: Mark Salter > 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