Re: [RFC] Allowing all threads of all|current process(es) to be resumed [new command + docs]

[Doug Evans <dje@google.com>]

On Sun, May 31, 2009 at 3:07 PM, Pedro Alves <pedro@codesourcery.com> 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
all-stop.

> Non-stop, however, avoids all these issues by working on top
> of an asynchronous target interface.

Indeed.

> 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
two alternatives.