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]

Extra Thread Info


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 <thid>".  (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



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