* Re: MI thread commands [not found] <1097854821.16300.ezmlm@sources.redhat.com> @ 2004-10-15 18:50 ` Jim Ingham 2004-10-18 21:05 ` Alain Magloire 0 siblings, 1 reply; 6+ messages in thread From: Jim Ingham @ 2004-10-15 18:50 UTC (permalink / raw) To: gdb 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. > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MI thread commands 2004-10-15 18:50 ` MI thread commands Jim Ingham @ 2004-10-18 21:05 ` Alain Magloire 0 siblings, 0 replies; 6+ messages in thread From: Alain Magloire @ 2004-10-18 21:05 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb > > 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 !!! ^ permalink raw reply [flat|nested] 6+ messages in thread
* MI thread commands
@ 2004-10-01 14:58 Fabian Cenedese
2004-10-14 18:53 ` Fabian Cenedese
0 siblings, 1 reply; 6+ messages in thread
From: Fabian Cenedese @ 2004-10-01 14:58 UTC (permalink / raw)
To: gdb
Hi
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, I
need 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)..]
Thanks
bye Fabi
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: MI thread commands 2004-10-01 14:58 Fabian Cenedese @ 2004-10-14 18:53 ` Fabian Cenedese 2004-10-15 2:36 ` Andrew Cagney 0 siblings, 1 reply; 6+ messages in thread From: Fabian Cenedese @ 2004-10-14 18:53 UTC (permalink / raw) To: gdb 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? Thanks bye Fabi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MI thread commands 2004-10-14 18:53 ` Fabian Cenedese @ 2004-10-15 2:36 ` Andrew Cagney 2004-10-15 12:50 ` Alain Magloire 0 siblings, 1 reply; 6+ messages in thread From: Andrew Cagney @ 2004-10-15 2:36 UTC (permalink / raw) To: Fabian Cenedese; +Cc: gdb > 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. Andrew ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MI thread commands 2004-10-15 2:36 ` Andrew Cagney @ 2004-10-15 12:50 ` Alain Magloire 0 siblings, 0 replies; 6+ messages in thread From: Alain Magloire @ 2004-10-15 12:50 UTC (permalink / raw) To: Andrew Cagney; +Cc: Fabian Cenedese, gdb > > > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-10-18 17:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1097854821.16300.ezmlm@sources.redhat.com>
2004-10-15 18:50 ` MI thread commands Jim Ingham
2004-10-18 21:05 ` Alain Magloire
2004-10-01 14:58 Fabian Cenedese
2004-10-14 18:53 ` Fabian Cenedese
2004-10-15 2:36 ` Andrew Cagney
2004-10-15 12:50 ` Alain Magloire
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).