This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Sun, May 31, 2009 at 3:07 PM, Pedro Alves <> 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
two alternatives.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]