This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI thread commands
- From: Jim Ingham <jingham at apple dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 15 Oct 2004 10:55:52 -0700
- Subject: Re: MI thread commands
- References: <1097854821.16300.ezmlm@sources.redhat.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.
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. 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...
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.
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.