RE: info thread

[Alain Magloire <alain@qnx.com>]

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf
> Of Daniel Jacobowitz
> Sent: Monday, September 25, 2006 10:52 AM
> To: Denis PILAT
> Cc: Mark Kettenis; nickrob@snap.net.nz; gdb@sourceware.org
> Subject: Re: info thread
> 
> On Mon, Sep 25, 2006 at 04:49:07PM +0200, Denis PILAT wrote:
> > About current thread, it is displayed by an asterisk with "info thread"
> > command, and gathered by Eclipse today from that output,
> > , whereas it could be from the  MI stop reply message.
> >
> > Do we need to have the current thread ID in one of the -thread-blabla
> > command ?
> > That would avoid storing it somewhere in the GUI.
> 
> I think this would be a good idea, since it would be so easy.  It will
> be simpler for consumers.  They should be able to keep track of it
> by watching stop replies and their own -thread-select commands, and
> some future notifier support for e.g. typing "thread 2" at a console,
> but there's no reason to make this hard.
> 

Yes, fortunately when the async "*stopped," appears it contains the
thread-id.  But the active tread is not necessary the one we are we stopped.
For example, we allow the user to issue commands to gdb so the user may
change the active thread, so having a notification would be great.

  I have a gnat/pr on this way back, the reasons that CDT/Debug/MI was using
"info threads" instead of -thread-list-ids were:
- -thread-list-all-threads was crashing (probably fixed by now)
- -thread-list-all-threads was not showing the newly created thread, i.e.
the MI command was not doing the same job as "info threads"

Note also some folks support thread names and add other information in the
"info threads" output.  To accommodate, it would be nice to change the
output of this command to list of name=values pairs, something like:
[{name="id",value="1"}{name="name",value="Driver thread"}...]