From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 23 Nov 1999 09:30:00 -0000 Message-id: <87yabpktkf.fsf@cygnus.com> References: <199911222334.PAA24695@andros.cygnus.com> X-SW-Source: 1999-q4/msg00314.html >>>>> "Stan" == Stan Shebs writes: Stan> However, an operating system may have additional info about Stan> threads that the user would like to see. Would this only happen at the OS level? In a Java program, each (Java) thread has a name and a ThreadGroup. It would be very useful to Java developers to see this information when debugging Java programs. Of course, that means interacting with the runtime. Stan> but the current kod code needs more work to be useful for Stan> threads in this way. For instance, it asks for all types of Stan> objects, but for threads we just want to ask about specific Stan> threads. Not only that, but KOD also has no way to map from the target's thread id to gdb's thread id. cf my KOD critique. IMNSHO KOD is the wrong way to go until it is redesigned and rewritten. Tom >From jimb@cygnus.com Tue Nov 23 13:00:00 1999 From: Jim Blandy To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: none Date: Tue, 23 Nov 1999 13:00:00 -0000 Message-id: References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00315.html Content-length: 2176 > > So, does the compiler use separate numbers in the debug for MMX > > registers and FP stack registers, or the same numbers? > > > > If the compiler uses separate register numbers, then we have the > > problems discussed before: as far as I can tell, GDB simply isn't set > > up to cope with the idea that certain bits might be part of two > > registers. > > > > If the compiler uses the same register numbers, how can the > > architecture-specific code tell whether GDB is accessing MM0 (which > > lives in R0) or ST(0) (which lives in R(TOS))? > > The architecture-specific code knows about TOS, right? It's part of > the status word, so it's available to GDB. Since TOS is handled the > same by all x86 platforms, we could use the value of TOS to define two > x86-specific functions to map between ST(i) and the corresponding MMj > register and back. > > Given these mapping functions, the code which implements the MMX view > of the FP registers could allow both reading and writing MMX registers > by accessing the corresponding ST(i) registers, each time using the > current value of TOS. > > Am I missing something obvious? If so, perhaps I don't understand how > the register views are (or would be) implemented. For register views, yes, we can do anything we please. However, when the compiler places a register in an MMX register value, we still get an old-fashioned symbol with a LOC_REGISTER. Register views don't come into it. As long as we only have a LOC_REGISTER, we don't have enough information to do the job right. We could add a new symbol LOC type, LOC_REGISTER_VIEW, which produces a struct value the same way a register view does. Then, we could have an architecture-specific hook can map certain register numbers in debugging information onto LOC_REGISTER_VIEW, instead of LOC_REGISTER. That might be the cleanest solution. It remains to be seen whether I can persuade the maintainers to accept register views at all. They could reasonably argue that this is all x86 hair, and should be isolated in x86 code. And I also have the feeling that there's something more general and cleaner we could do here. I'll need to think about it. >From jtc@redback.com Tue Nov 23 13:32:00 1999 From: jtc@redback.com (J.T. Conklin) To: Stan Shebs Cc: gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 23 Nov 1999 13:32:00 -0000 Message-id: <5m7lj8x5bp.fsf@jtc.redbacknetworks.com> References: <199911222334.PAA24695@andros.cygnus.com> X-SW-Source: 1999-q4/msg00316.html Content-length: 3347 >>>>> "Stan" == Stan Shebs writes: Stan> I have a small GDB task for which I'm collecting opinions. Stan> Should GDB include a special mechanism to get and display extra Stan> info about threads? Right now GDB has a simple generic display Stan> for threads: thread number, thread identifier, stack frame. The Stan> thread identifier is a string that may vary from system to Stan> system, but is generally expected to be a unique identifier of Stan> some sort, such as "process 35 thread 217" or "thread 42.21". 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. Another problem is that we don't know what extra thread info is useful to the user and what is extraneous. If we retrieve too much from the target, "info threads" may take a very long time and the output may be cluttered. If we retrieve too little, the user may not be able to get at what he needs. 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. Stan> Opinions? I'd like to resolve this fairly quickly - eCos thread Stan> info is one of the few areas where eCos GDB differs from regular Stan> GDB, but there shouldn't be a difference at all. I'm presently Stan> leaning towards the second choice, but don't feel strongly about Stan> it. If support for extra thread info is brought into GDB, I believe that it must be "better" than what can be done by user defined functions. Also, since that mechanism already exists and works well, I see no reason to rush if the haste will result in something that we'll curse in the years to come. For reference, enclosed is a script I wrote to traverse the task list on VxWorks. --jtc set $WIND_READY = 0x00 set $WIND_SUSPEND = 0x01 set $WIND_PEND = 0x02 set $WIND_DELAY = 0x04 set $WIND_DEAD = 0x08 define show_task set $tcb = (WIND_TCB *) $arg0 printf "%-13.13s%8x %8x %3d ", $tcb->name, $tcb->entry, $tcb, $tcb->priority if ($tcb->status == $WIND_READY) printf "READY " end if ($tcb->status == $WIND_DELAY) printf "DELAY " end if ($tcb->status == ($WIND_DELAY | $WIND_SUSPEND)) printf "DELAY+S " end if ($tcb->status == $WIND_PEND) printf "PEND " end if ($tcb->status == ($WIND_PEND | $WIND_DELAY)) printf "PEND+T " end if ($tcb->status == ($WIND_PEND | $WIND_SUSPEND)) printf "PEND+S " end if ($tcb->status == ($WIND_PEND | $WIND_DELAY | $WIND_SUSPEND)) printf "PEND+S+T " end if ($tcb->status == $WIND_SUSPEND) printf "SUSPEND " end if ($tcb->status == $WIND_DEAD) printf "DEAD " end printf "\n" end define show_task_summary set $n = activeQHead.pFirstNode while $n != 0 set $tmp = ((WIND_TCB *) ((char *) $n - 0x20)) show_task $tmp set $n = (Q_NODE *) $n->qPriv1 end end -- J.T. Conklin RedBack Networks >From shebs@cygnus.com Tue Nov 23 14:11:00 1999 From: Stan Shebs To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 23 Nov 1999 14:11:00 -0000 Message-id: <199911232211.OAA25604@andros.cygnus.com> References: <5m7lj8x5bp.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00317.html Content-length: 2229 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 >From jimb@cygnus.com Tue Nov 23 14:15:00 1999 From: Jim Blandy To: Bernard Mainguenaud Cc: gdb@sourceware.cygnus.com Subject: Re: Gdb target for kdb Date: Tue, 23 Nov 1999 14:15:00 -0000 Message-id: References: <199911231620.RAA29254@gabin.frcl.bull.fr> X-SW-Source: 1999-q4/msg00318.html Content-length: 657 > We intend to use gdb to debug a running Linux kernel connected > to another Linux box via an asynchronous line. For this purpose, > we are considering developping a new gdb target that interfaces > with kdb. Has anyone ever tried to develop such a kdb target > before ? GDB has facilities for talking with ROM monitors. You simply tell GDB what the monitor's prompt looks like, how it prints registers, how it dumps memory, and so on, and GDB will act as a very fast typist. :) Kdb's output might be close enough to a ROM monitor that this would work. gdb/monitor.h describes the general principles, and any gdb/*-rom.c file can furnish an example. >From taylor@cygnus.com Tue Nov 23 15:51:00 1999 From: David Taylor To: Bernard Mainguenaud Cc: gdb@sourceware.cygnus.com, Jim Blandy Subject: Re: Gdb target for kdb Date: Tue, 23 Nov 1999 15:51:00 -0000 Message-id: <199911232344.SAA22324@texas.cygnus.com> X-SW-Source: 1999-q4/msg00319.html Content-length: 967 From: Jim Blandy Date: 23 Nov 1999 16:04:07 -0500 > We intend to use gdb to debug a running Linux kernel connected > to another Linux box via an asynchronous line. For this purpose, > we are considering developping a new gdb target that interfaces > with kdb. Has anyone ever tried to develop such a kdb target > before ? GDB has facilities for talking with ROM monitors. You simply tell GDB what the monitor's prompt looks like, how it prints registers, how it dumps memory, and so on, and GDB will act as a very fast typist. :) Kdb's output might be close enough to a ROM monitor that this would work. gdb/monitor.h describes the general principles, and any gdb/*-rom.c file can furnish an example. Another thing to look at is kgdb from Sun Microsystems. Unfortunately, I don't know many of the details (esp. the precise url). If you do a search at www.sun.com it should find it.