Re: [cdt-debug-dev] multi-threaded programs and GDB interface

[Daniel Jacobowitz <drow@xxxxxxxxx>]

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.

-- 
Daniel Jacobowitz
CodeSourcery