Re: MI thread commands

["Alain Magloire" <alain at qnx dot com>]

> 
> One thought here is that getting all this info for all threads is  
> currently expensive in gdb.  You need to be careful about anything you  
> have to do each time the debugger steps, since people really notice  
> slowdowns in stepping performance.  Unless you are displaying all this  
> info for every thread in the program, you might not want to fetch it.
> 

Agreed.  On some architecture like SH4(MIPS) it is a killer.
Doing "info threads" was equivalent of walking the stackframes. 

Kris W. did something for me, for the QNX/Neutrino a special commands
that return the list of tids.


> Xcode just uses -thread-list-ids (which you might want to enhance to  
> add the "extra" bit since that would be useful to display in a "thread  
> list or popup" UI element.

At the beginning, I though "-thread-list-ids" was a ligther version
of  "info threads" but I had problems with the command (beside the crashing),
it did not show newly created threads.  A GNAT PR was create for this.

> We only get more info about a thread if we  
> actually have to display it's stack.  For that reason, we have never  
> felt the need to implement thread-list-all-threads...
> 

Yes, but we wanted to go further meaning showing when threads are created/destroyed
even when the inferior is running,  I have such code but ... it is terrible 8-)
based on the "[System ..]" console output tag.  Andrew C. pointed me in the right
direction with the oberser.c code and libthread_db.so, but I lack time to
look at this option seriously.

> Also, I am sure you know this, but remember also that the active thread  
> is not necessarily the thread that you stopped at.  The use can change  
> the thread (they can even do it in the console...) so gdb needs to  
> issue and the UI needs to pick up thread changed notifications.
> 

Agreed.
We are changing our things work with the IDE interface, so now if you
want to do some actions, say evaluating an expression, the IDE must provide
a context to evaluate (stackframe/thread) :

// save current context
...
-thread-select 2
-stack-select-frame 4
-data-evaluate-expresion "foobar"
...
// restore context

It is a little heavy, but seems to work ok.  So we make
sure that we do things in the right context.


> Jim
> 
> On Oct 15, 2004, at 8:40 AM, gdb-digest-help@sources.redhat.com wrote:
> 
> >
> >
> >>
> >>> Hi
> >>>
> >>> I didn't get a reply on this one so I thought I try again.
> >>>
> >>>
> >>>>> What was the intention behind -thread-info? It's not explained in  
> >>>>> the
> >>>>> manual and also not implemented (so much to "Read the source,  
> >>>>> Luke").
> >>>>> Should this bring the info that is available with "info threads"  
> >>>>> but for only
> >>>>> one thread? Is there another possibility to get e.g. the thread  
> >>>>> name?
> >>>>>
> >>>>> I made my try with the -thread-list-all-threads command, but I'm  
> >>>>> not
> >>>>> sure about the output format as it's nowhere described (Hey Bob,  
> >>>>> thanks
> >>>>> for your rules :) Is this sensible? Or is it one level too much  
> >>>>> (the
> >>>>> "threads=" level)?
> >>>>>
> >>>>> ^done,threads=[thread={id="12",pid="945832",extra=" Name:  
> >>>>> UserTaskName, State: 0
> >>>>> 002, Priority:  
> >>>>> 0007",frame={func="CTaskTemplateClass::Action",args=[{name="this"
> >>>>> ,value="0xe6ea8"}],file="N:/Temp/ToThrow/psoism/applicat/src/ 
> >>>>> CTaskTemplateClass.
> >>>>> cpp",line="454"}},thread={id="11",pid="956152",extra=" Name:  
> >>>>> IMP_MAS, State: 000
> >>>>> 9, Priority:  
> >>>>> 0000",frame={func="CINOSTask::MainLoop",args= 
> >>>>> [{name="this",value="0
> >>>>> xe96f8"}],file="N:/Temp/ToThrow/psoism/os/inos/Src/ 
> >>>>> Inos.cpp",line="856"}}..(snipped)..]
> >>>
> >>>
> >>> Another problem I have is the active thread. If the info thread  
> >>> command is issued
> >>> on the CLI gdb will indicate the selected thread with a '*' in front  
> >>> of it. Obviously
> >>> that's not possible with the mi. How can this information be  
> >>> returned? Is there
> >>> a way to add it to the -thread-list-all-threads, e.g. with a new  
> >>> field "active" only
> >>> present in the active thread? Or should it be omitted in this  
> >>> command and put
> >>> into a new/other mi command? e.g. the above mentioned -thread-info?
> >>
> >> Does a GUI, where all threads are displayed equal, have an "active"
> >> thread?  I guess you're looking to identify the thread at the head of
> >> the list of threads that had a reason to stop - breakpoint, signal,  
> >> ...
> >>
> >> If MI clients think it's useful, it can be added.
> >>
> >
> > When the inferior become suspended, in the response usually there is a  
> > thread-id
> > for example:
> > *stopped,reason="breakpoint-hit",thread-id=".."
> >
> > So the GUI will know the active thread.
> > I've seen, however times where the thread-id was not in for some  
> > reason.
> > In this case, for backward compatibility reason, we fallback to use  
> > "info threads"
> > I believe there was a PR on this on GNATS.  So far the latest gdbs  
> > seem to come back
> > with a thread-id that make this PR less of a priority.
> >
> >
> >
> 


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!