Re: MI thread commands

["Alain Magloire" <alain@qnx.com>]

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