From: Stan Shebs <shebs@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Extra Thread Info
Date: Mon, 22 Nov 1999 15:34:00 -0000 [thread overview]
Message-ID: <199911222334.PAA24695@andros.cygnus.com> (raw)
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
next reply other threads:[~1999-11-22 15:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-11-22 15:34 Stan Shebs [this message]
1999-11-23 9:30 ` Tom Tromey
1999-11-24 17:30 ` Chris Faylor
[not found] <199911232211.OAA25604@andros.cygnus.com>
1999-11-23 16:34 ` Mark Salter
1999-11-23 17:40 ` Stan Shebs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199911222334.PAA24695@andros.cygnus.com \
--to=shebs@cygnus.com \
--cc=gdb@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox