From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Salter To: shebs@cygnus.com Cc: jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 23 Nov 1999 16:34:00 -0000 Message-id: <199911240034.TAA11366@msalter2.cygnus.com> References: <199911232211.OAA25604@andros.cygnus.com> X-SW-Source: 1999-q4/msg00320.html >>>>> 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