info thread

> -----Original Message-----
> From: gdb-ownersourceware.org [mailto:gdb-ownersourceware.org] On Behalf
> Of Daniel Jacobowitz
> Sent: Monday, September 25, 2006 10:52 AM
> To: Denis PILAT
> Cc: Mark Kettenis; nickrobsnap.net.nz; gdbsourceware.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&q
uot;,value="Driver thread"}...] 

On Mon, Sep 25, 2006 at 11:24:44AM -0400, Alain Magloire
wrote:
>   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&q
uot;,value="Driver thread"}...] 

Um... really?

(gdb) interpreter-exec mi -thread-list-all-threads
^error,msg="Undefined mi command:
thread-list-all-threads (missing implementation)"

I think you're thinking of -thread-list-ids.  Ah, this is
mi/674.
It's also mi/1040.  Both of which suggest *stopped 

We could add the thread to -thread-list-ids, too.

Something to keep in mind: the thread "extra info"
is expensive to
collect on some platforms, e.g. requires asking the remote
stub for
details on each individual thread.

-- 
Daniel Jacobowitz
CodeSourcery