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
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Tom Tromey <tromey at redhat dot com>
- Date: Fri, 16 Dec 2011 18:46:40 +0000
- Subject: Re: [RFC/WIP PATCH 13/14] Make "thread apply all" only loop over threads in the current set
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Tuesday 29 November 2011 21:47:09, Tom Tromey wrote:
> >>>>> "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.
Yeah. In a way, it's still "all" something. But instead of
all in the debug session, it's "all" in current focus. It's
a similar change as done to, e.g., "continue -a", where -a means "all
in current focus". I actually tried out the change after finding this:
"(...) a "upcmode" of operation where commands like breakpoint, info threads, .. apply
only to UPC threads (a set in your example). Also, "c -a" like commands apply only
to UPC threads. Same with "thread apply all". In essence you are focusing your
debugging to a group of threads. Switching off "upcmode" makes everything go back
to normal (in your case selecting a thread set "all" turns off this feature)."
and thinking that such upcmode could easily be reimplemented this way.
But I only now notice that they also change "info threads". Hmm.
I'm dropping this patch for now.
> 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)
I don't think that is a good idea either.
> 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
> to use.
That one I think makes sense. I implemented it for experimentation.
> "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
This may be what makes most sense.