This is the mail archive of the
mailing list for the GDB project.
Re: [RFC/WIP PATCH 13/14] Make "thread apply all" only loop over threads in the current set
>>>>> "Pedro" == Pedro Alves <email@example.com> writes:
Pedro> This makes "thread apply all" only loop over threads in the current
Pedro> set instead of always all threads.
It seems to me that "thread apply" already has a thread argument, which
could be syntactically extended to cope with sets:
thread apply [1.*] print x
Then I think the existing syntax can just be mapped to a set:
thread apply 1 2 3 print x
=> thread apply [1,2,3] print x
thread apply all print x
=> thread apply [*] print x
(I didn't read the itset patch yet so I don't know if this is still
the right syntax, but you get the idea.)
If you considered this and rejected it, I would be interested in your
I am not strongly wedded to this idea.
I wonder if your idea might be confusing for users, since "all" is an
absolute word, but this patch makes it not so.
Pedro> I think it might make sense to make "info threads" only list threads
Pedro> of the current focus too. WDYT?
If a command can determine whether it has an explicit prefix (and TBH I
am not sure it is a good idea to allow this -- and I didn't read that
patch yet either) then you could have it use the current focus if and
only if the focus is explicit.
[1.*]> info thread
=> all threads
[1.*]> [1.*] info thread
=> just threads in inferior 1
If there is a set meaning "the current focus set" you could:
[1.*]> [$] info thread
... giving the current set some short moniker like "$" makes it easier
"info thread" takes thread arguments, so perhaps the same rewriting idea
used above applies. This approach would work even without a command
knowing whether it has explicit context:
(gdb) info thread 1 2 3
=> info thread [1,2,3]
(gdb) info thread [$]
=> focused threads
(gdb) info thread [1.*]
=> threads of inferior 1
In any case if these commands respect the focus set, then we also have
to define what happens if they are passed explicit threads.