RE: info thread

RE: info thread

[Alain Magloire]

> 
> (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 :-)
> 

Mea culpa.

RE: info thread

[Alain Magloire]

> From: Denis PILAT [mailto:denis.pilat@st.com]
> Sent: Wednesday, September 27, 2006 10:18 AM
> To: Alain Magloire
> Cc: Daniel Jacobowitz; nickrob@snap.net.nz; gdb@sourceware.org
> Subject: Re: info thread
> 
> 
> 
> Alain Magloire wrote:
> 
> >
> >>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.
> >>
> >>
> >
> >Noted, but some platforms put some extra stuff in the output of "info
> >threads" like thread names, states, mutexes etc ... this information is
> then
> >retrieve by the IDE and shownn to the user.
> >
> Yes but to display this "extra stuffs" they have to customize their
> Eclipse (or any UI) to implement a parser for that.
> 
> I think it will be more generic and cost less (in term of execution
> time) if "extra information" could be accessible thru an other mi
> command than -thread-list-ids.
> Generic part of the UI then calls -thread-list-ids
> Targets that want to display more information then just call a more
> complete command like -thread-list-all-threads
> or -thread-info on each thread.
> 
> 

Agreed, if we the UI views are smart enough to tell which threads are
visible to the users then the implementation can be lazy in getting the
info.

> What I propose is the following:
> 
> -thread-list-ids :
> INPUT: none
> OUTPUT:
>     o list of IDs
>     o Current thread could be the first (or last) item of the list, or
>     warned by an asterisk
> 
> -thread-list-all-threads
> INPUT: none
> OUTPUT:
>    o like  -thread-list-ids
>    o plus the list of "extra information" per thread
> 
> 
> -thread-info
> INPUT: thread ID as an optional parameter, if not given the following
>     concerns current thread
> OUTPUT:
>     o thread ID (could be used to determine which is the current
>     thread if not given in parameter)
>     o extra information
>     o stack frame
> 
> 

OK.  And in term of format, are we talking tuple/list?  There was some
inconsistencies in the old MI versions.  Also for extra information you are
probably mean "optional extra information" will that be an opaque string or
name=value pairs.

> 
> Apart from the debate let me give you some measurements I did on a
> 100 threads program that runs on a board, debugged thru jtag.
> Figures for the "info thread" CLI command only:
> 70 % of the time is spent in getting the stack frame for all threads
> 1% on the "extra info"
> 29% on other stuff out of the loop that collect thread above information.
> 
> Stack frame is the one that takes the most since it requires to switch
> the current thread and print the stack. Switching takes 60% of that
> time. Moreover extra information are reduced for our target.
> 
> Please note that the total time is 7.2 seconds for this example !

On some architecture "info threads" can make things extremely slow, since
the IDE will have to poll at every step to discover created/destroyed
threads.  For the long run we should probably look at notifications.

RE: info thread

[Alain Magloire]

> 
> 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.
>

Noted, but some platforms put some extra stuff in the output of "info
threads" like thread names, states, mutexes etc ... this information is then
retrieve by the IDE and shownn to the user.

It is my understanding, that the output is platform dependent. Are you
suggesting a new command to retrieve this info? I was hopping we could stuff
this in the output of -thread-list-ids.

Basically, we would like to retrieve more information on a thread what is
the best way for MI?
 

Re: info thread

[Daniel Jacobowitz]

I really wish the same set of people read both this list and
cdt-debug-dev, or even cdt-debug-dev and dmi-discuss if that's
more appropriate... I keep ending up saying the same thing on both :-)
And my message to cdt-debug-dev isn't in the web archive yet.

On Mon, Sep 25, 2006 at 01:27:41PM -0400, Alain Magloire wrote:
> It is my understanding, that the output is platform dependent. Are you
> suggesting a new command to retrieve this info? I was hopping we could stuff
> this in the output of -thread-list-ids.
> 
> Basically, we would like to retrieve more information on a thread what is
> the best way for MI?

I wrote:

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.



Pawel's just responded:

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.


Alain, Denis, what do you think?

-- 
Daniel Jacobowitz
CodeSourcery

Re: info thread

[Denis PILAT]

Alain Magloire wrote:

>
>>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.
>>
>>
>
>Noted, but some platforms put some extra stuff in the output of "info
>threads" like thread names, states, mutexes etc ... this information is then
>retrieve by the IDE and shownn to the user.
>
Yes but to display this "extra stuffs" they have to customize their
Eclipse (or any UI) to implement a parser for that.

I think it will be more generic and cost less (in term of execution
time) if "extra information" could be accessible thru an other mi
command than -thread-list-ids.
Generic part of the UI then calls -thread-list-ids
Targets that want to display more information then just call a more
complete command like -thread-list-all-threads
or -thread-info on each thread.


What I propose is the following:

-thread-list-ids :
INPUT: none
OUTPUT:
    o list of IDs
    o Current thread could be the first (or last) item of the list, or
    warned by an asterisk

-thread-list-all-threads
INPUT: none
OUTPUT:
   o like  -thread-list-ids
   o plus the list of "extra information" per thread


-thread-info
INPUT: thread ID as an optional parameter, if not given the following
    concerns current thread
OUTPUT:
    o thread ID (could be used to determine which is the current
    thread if not given in parameter)
    o extra information
    o stack frame



Apart from the debate let me give you some measurements I did on a
100 threads program that runs on a board, debugged thru jtag.
Figures for the "info thread" CLI command only:
70 % of the time is spent in getting the stack frame for all threads
1% on the "extra info"
29% on other stuff out of the loop that collect thread above information.

Stack frame is the one that takes the most since it requires to switch 
the current thread and print the stack. Switching takes 60% of that 
time. Moreover extra information are reduced for our target.

Please note that the total time is 7.2 seconds for this example !

RE: info thread

[Alain Magloire]

> -----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"}...] 

Re: info thread

[Daniel Jacobowitz]

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

Re: info thread

[Nick Roberts]

> Daniel,

> I'd like your opinion about a feature that we need to implement in gdb. We'd
> like to choose the solution that has the best chance to be accepted and
> integrated in GDB.

This isn't a patch so isn't the gdb mailing list more appropriate?

> As you may know, Eclipse is using "info threads" command to get thread
> Ids. The problem is that some part of this command is not used by Eclipse and
> can take a lot of time to execute when the debugger is remotely connected to
> a board. In our case we have a 100 threads application and the info threads
> takes a lot of time to execute, and in Eclipse this command is run each time
> the user push the "next" button, which leads to a non usable graphical
> interface.  

Some form of event notification would be desirable where GDB tells the
front end that the relevant information has changed (pie in the sky thought,
I have no idea how to implement it).

>            The stack frame information is not used at all by Eclipse and
> removing this part saves 70% of the execution time in our case.  Eclipse used
> the thread list IDs and the extra information which are target specific
> (usually we get thread names in these information but it can be whatever the
> targets puts)

> The solutions we thought are the following:

> Sol 1 - developping a new MI command that gives the above target extra
> information only (ie -thread-list-extra-info) of implementing a
> non-implemented one with a parameter.  I see in the doc that
> -thread-list-all-threads is not specified for instance.

> Then we need to modify Eclipse so that it uses MI command "-thread-list-ids"
> plus this command to get all he needs.  This can be an Eclipse contribution
> as well, I need to ask to Eclipse maintainer as well.

There is only a slot for -thread-list-all-threads and no implementation so I
see no harm in using a new name, especially if your command doesn't list _all_
the info.  I'm not very familiar with debugging threaded applications but I
think the command should be general and not just suited to your requirements.
Also if there is a common usage pattern then I think it would be good if that
information can be obtained with one MI command rather than two/many.  That is
the essence of many of the changes that I have made to MI.

> Sol 2 - a parameter to the "info thread" CLI command that ask gdb to not
> print stack frame information but only thread IDs lists and extra_info.
>  (ie info thread nostackframe)

I think this would be a bad idea because CLI output is for human consumption,
and someone could quite reasonably change the output later and break your
front end.  With MI the intention is to change the output in predictable and
manageable ways.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: info thread

[Denis PILAT]

Nick Roberts wrote:

>>Sol 1 - developping a new MI command that gives the above target extra
>>information only (ie -thread-list-extra-info) or implementing a
>>non-implemented one with a parameter.  I see in the doc that
>>-thread-list-all-threads is not specified for instance.
>>    
>>
>>Then we need to modify Eclipse so that it uses MI command "-thread-list-ids"
>>plus this command to get all info.  This can be an Eclipse contribution
>>as well, I need to ask to Eclipse maintainer as well.
>>    
>>
>
>There is only a slot for -thread-list-all-threads and no implementation so I
>see no harm in using a new name, especially if your command doesn't list _all_
>the info.  I'm not very familiar with debugging threaded applications but I
>think the command should be general and not just suited to your requirements.
>Also if there is a common usage pattern then I think it would be good if that
>information can be obtained with one MI command rather than two/many.  That is
>the essence of many of the changes that I have made to MI.
>  
>

Daniel wrote:
> I think we've got two visible options: make -thread-list-all-threads
> do exactly what you want, without stack information, or make
> -thread-info return the target extra info for the thread.  Either
> makes sense to me.  Might as well make -thread-list-all-threads
> do it.


Daniel, Nick,
Thanks for your answers.
Let's continue this thread on the gdb mailing list as Nick suggested.

I still don't have answer from the Eclipse community but reading my 
email, it's not a surprise ... I think it was not so easy to read,
I was probably drunk when I wrote it.


Where can I find the specifications for the MI commands 
-thread-list-all-threads and -thread-info ?


Denis

Re: info thread

[Daniel Jacobowitz]

On Tue, Sep 19, 2006 at 03:15:40PM +0200, Denis PILAT wrote:
> Where can I find the specifications for the MI commands 
> -thread-list-all-threads and -thread-info ?

You can't: I think we get to make one up that is generally useful :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: info thread

[Nick Roberts]

 > Where can I find the specifications for the MI commands 
 > -thread-list-all-threads and -thread-info ?

There is no specification so we can only guess what was intended.  Perhaps
-thread-info was just meant to give info for the selected thread which
presumably would not take long to compute even with all the details.  In any
case, as Daniel says, the problem is to devise one(s) which is/are generally
useful.

I would guess the reason that they haven't already been implemented is that
the other information is kernel/OS dependent e.g on GNU/Linux I get:


(gdb) inf threads
  5 Thread -1240261728 (LWP 2575)  0x00c12b68 in clone () from /lib/libc.so.6
  4 Thread -1229771872 (LWP 2574)  0x08048863 in myproc (ptr_i=0xbff15ca4)
    at pthreadtest.c:75
  3 Thread -1219282016 (LWP 2573)  0x00c12b68 in clone () from /lib/libc.so.6
  2 Thread -1208792160 (LWP 2572)  0x08048833 in myproc (ptr_i=0xbff15c9c)
    at pthreadtest.c:78
* 1 Thread -1208789312 (LWP 2554)  main () at pthreadtest.c:99

but presumably not all systems have the concept of a lightweight process,
and maybe the numbering of the threads is different.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: info thread

[Daniel Jacobowitz]

On Wed, Sep 20, 2006 at 08:53:19AM +1200, Nick Roberts wrote:
> There is no specification so we can only guess what was intended.  Perhaps
> -thread-info was just meant to give info for the selected thread which
> presumably would not take long to compute even with all the details.  In any
> case, as Daniel says, the problem is to devise one(s) which is/are generally
> useful.
> 
> I would guess the reason that they haven't already been implemented is that
> the other information is kernel/OS dependent e.g on GNU/Linux I get:

This isn't really relevant.  It breaks down into just a few parts in GDB
parlance:

- The GDB ID.  That's "1", "2", et cetera in your example.
- The thread ID, produced by to_pid_to_str, e.g. "Thread -BLAH (LWP
BLAH)".  This is just a string.
- The thread extra info.  Not present in your example, but e.g.
"(Exiting)" or "(not ready)".
- The thread's current stack frame.

That last, I think, is not useful in MI.  There's commands to fetch it
when it's wanted, and it might not be by some consumers.  And it will
show up with -thread-select already.  So, I would recommend including
only the GDB ID (as from -thread-list-ids) and the additional
information.

Whether they should be one field or two is anybody's guess.

-- 
Daniel Jacobowitz
CodeSourcery

Re: info thread

[Mark Kettenis]

> Date: Tue, 19 Sep 2006 17:03:16 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> This isn't really relevant.  It breaks down into just a few parts in GDB
> parlance:
> 
> - The GDB ID.  That's "1", "2", et cetera in your example.
> - The thread ID, produced by to_pid_to_str, e.g. "Thread -BLAH (LWP
> BLAH)".  This is just a string.
> - The thread extra info.  Not present in your example, but e.g.
> "(Exiting)" or "(not ready)".
> - The thread's current stack frame.
> 
> That last, I think, is not useful in MI.  There's commands to fetch it
> when it's wanted, and it might not be by some consumers.  And it will
> show up with -thread-select already.  So, I would recommend including
> only the GDB ID (as from -thread-list-ids) and the additional
> information.

Note that the formatting of the thread ID produced by to_pid_to_str is
highly dependent on the specific threads model in use.  The thread
extra info is also mostly free-form.  That means it might not be wise
to export that information in the MI interface.

Mark

Re: info thread

[Daniel Jacobowitz]

On Sat, Sep 23, 2006 at 09:05:56PM +0200, Mark Kettenis wrote:
> Note that the formatting of the thread ID produced by to_pid_to_str is
> highly dependent on the specific threads model in use.  The thread
> extra info is also mostly free-form.  That means it might not be wise
> to export that information in the MI interface.

Except as strings, presumably?

It's supposed to be useful to users; the extra information is supposed
to be exactly what would be useful in a dialog box listing threads.

I agree that some words in the MI documentation about which strings
to consider "opaque" may be in order, here and in other places (e.g.
relating to frames...)

-- 
Daniel Jacobowitz
CodeSourcery

Re: info thread

[Denis PILAT]

Daniel Jacobowitz wrote:

>On Sat, Sep 23, 2006 at 09:05:56PM +0200, Mark Kettenis wrote:
>  
>
>>Note that the formatting of the thread ID produced by to_pid_to_str is
>>highly dependent on the specific threads model in use.  The thread
>>extra info is also mostly free-form.  That means it might not be wise
>>to export that information in the MI interface.
>>    
>>
>
>Except as strings, presumably?
>
>It's supposed to be useful to users; the extra information is supposed
>to be exactly what would be useful in a dialog box listing threads.
>
Some GDB target displays thread priority and some usefull information in 
that string.
In ST we display the thread's name for some targets for instance.
I think we must keep it either in MI command -thread-list-all-threads or 
in a new MI command.



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.

Denis

Re: info thread

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: info thread

[Michael Snyder]

On Sat, 2006-09-23 at 17:59 -0400, Daniel Jacobowitz wrote:
> On Sat, Sep 23, 2006 at 09:05:56PM +0200, Mark Kettenis wrote:
> > Note that the formatting of the thread ID produced by to_pid_to_str is
> > highly dependent on the specific threads model in use.  The thread
> > extra info is also mostly free-form.  That means it might not be wise
> > to export that information in the MI interface.
> 
> Except as strings, presumably?
> 
> It's supposed to be useful to users; the extra information is supposed
> to be exactly what would be useful in a dialog box listing threads.

Well, except that I don't think there's an actual spec for it.  
I assume the target-side implementer can pretty much supply
anything he wants.

> I agree that some words in the MI documentation about which strings
> to consider "opaque" may be in order, here and in other places (e.g.
> relating to frames...)

Perhaps something to the effect that no guarantees are offered...