This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
- From: Doug Evans <dje at google dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: tromey at redhat dot com, gdb-patches at sourceware dot org
- Date: Mon, 1 Jun 2009 08:55:39 -0700
- Subject: Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
On Sun, May 31, 2009 at 3:07 PM, Pedro Alves <firstname.lastname@example.org> wrote:
> Re. 'c -t 1 2 3', and similars, you're skipping a lot of ground.
Whoa. Apologies for putting you through all that typing :-(. It was
just an off-the-cuff example and was certainly *not* aimed at
> Non-stop, however, avoids all these issues by working on top
> of an asynchronous target interface.
> My patch simply attempts at making all-stop multi-inferior behave
> the same as multi-forks + all-stop worked ever since it was added, so
> that we can continue lifting gdb's age old single-inferior design
> restrictions. ?E.g., trying to resume all forks is still a very
> limited experience, since GDB will only insert breakpoints in one
> of the forks... ?DICOS doesn't have this issue (breakpoints are visible
> to all processes), so resuming all inferiors is a feature that I can
> claim is useable today on some targets.
> I'm not saying that we should stick to this new switch forever, but
> IMNSHO, making gdb a parallel debugger inevitably takes experimentation
> and user feedback (this is nothing new: we can consider the multi-forks
> the first experimentation).
I guess I'm a bit confused (no claim is made that that's unexpected :-)).
I was offering an alternative. I'd still like to hear what you think
of adding a modifier to "continue", etc. instead. I'm not wedded to
it of course. In part it seemed like a good time to talk about the