On Mon, Sep 25, 2006 at 09:50:44AM -0700, Pawel Piech wrote:
Hi Denis,
I'm working on an alternative implementation of a GDB-based debugger in
Eclipse, and I do have a comment for the -thread-info command you are
considering.
I would expect that:
- the command would return information only of the currently selected
thread,
- the OS name and OS ID would be the main pieces of information,
- stack information was NOT included, since it's expensive, and
-stack-list-frames is used for the purpose
- for kernel debuggers, it would be good if it returned whether the
thread is interruptible or not.
There are, in the GDB manual, three related commands: -thread-info
(unimplemented), -thread-list-all-threads (unimplemented), and
-thread-list-ids. What I've been asking on the GDB list is which
information is useful for -thread-list-all-threads versus -thread-info.
Collecting data like "is this thread interruptible" is definitely
important and GDB has a mechanism for it already. But you have to
do round trips with the target to get this sort of thing. And
currently you have to do that for the OS name too when talking
to a remote target.
So: is there a useful middle ground between -thread-list-ids
(definitely shouldn't return it) and -thread-info (definitely
should) for -thread-list-all-threads to fill? Or should we just
do one at a time, and let e.g. the client request extra info
on specific threads which are currently visible in a scrolling
pane?
In the mean time, I think that implementing -thread-info and
adding the current thread to -thread-list-ids are both useful
I see what you're getting at. My intent is to take advantage of
lazy-loading and only request thread-info for threads that are visible
in the UI. But even then, requesting information for 20 or so threads
one at a time could be painfully slow. So if -thread-list-all-threads
were to return the same info as -thread-info, and if it took a list of
thread IDs as an optional argument, that would solve this problem
perfectly.