This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI thread commands
- From: "Alain Magloire" <alain at qnx dot com>
- To: jingham at apple dot com (Jim Ingham)
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 18 Oct 2004 13:32:07 -0400 (EDT)
- Subject: Re: MI thread commands
>
> 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 !!!