This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: info thread
- From: Daniel Jacobowitz <drow at false dot org>
- To: Alain Magloire <alain at qnx dot com>
- Cc: Denis PILAT <denis dot pilat at st dot com>, nickrob at snap dot net dot nz, gdb at sourceware dot org
- Date: Mon, 25 Sep 2006 11:31:15 -0400
- Subject: Re: info thread
- References: <3518719F06577C4F85DA618E3C37AB9106B12AA1@nimbus.ott.qnx.com>
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",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