From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: gdb@sourceware.cygnus.com Subject: Extra Thread Info Date: Mon, 22 Nov 1999 15:34:00 -0000 Message-id: <199911222334.PAA24695@andros.cygnus.com> X-SW-Source: 1999-q4/msg00309.html I have a small GDB task for which I'm collecting opinions. Should GDB include a special mechanism to get and display extra info about threads? Right now GDB has a simple generic display for threads: thread number, thread identifier, stack frame. The thread identifier is a string that may vary from system to system, but is generally expected to be a unique identifier of some sort, such as "process 35 thread 217" or "thread 42.21". However, an operating system may have additional info about threads that the user would like to see. For instance, eCos threads (the motivation for this task) have a name and other attributes, such as priority and handle. Similarly Posix threads have a scheduling attribute, stack base, and stack size. From the user's point of view, these all ought to appear using the same commands; either in "info threads", after the other data, or perhaps a new command "info extra ". (I'm interested in opinions on that issue too.) There appear to me to be three major approaches. The first is to say "platform-specific", keep this out of GDB core code, and implement display commands in platform-specific files. This is attractive for simplicity, but then every platform would likely come up with different implementations and there would be less consistency for users shifting between, say, eCos, Linux, and Solaris. The second approach is to introduce a new optional target vector entry that gets extra thread info. Then "info threads" just gets any extra info when requested, and dumps out whatever it gets back. This is what Cygnus' special GDB for eCos does now. The third approach is to make use of the kernel object display (kod) mechanism that was recently introduced. This makes sense because threads are just another kind of kernel object, but the current kod code needs more work to be useful for threads in this way. For instance, it asks for all types of objects, but for threads we just want to ask about specific threads. Opinions? I'd like to resolve this fairly quickly - eCos thread info is one of the few areas where eCos GDB differs from regular GDB, but there shouldn't be a difference at all. I'm presently leaning towards the second choice, but don't feel strongly about it. Stan