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

[Pedro Alves]

On Sunday 31 May 2009 19:29:19, Tom Tromey wrote:
> >>>>> "Doug" == Doug Evans <dje@google.com> writes:
> 
> Doug> [And IWBN if there were a way to continue a subgroup of threads though
> Doug> I realize "c N" is already taken. "c [-a] [-t T1 T2 T3] [--] [N]"?  I
> Doug> realize that's perhaps not ideal, but short of adding another command
> Doug> it's the first thing that came to me. :-) And no claim is made that
> Doug> this hasn't been discussed before ...]
> 
> Yeah, I think this is the "itset" idea that Stan mentioned and that
> Pedro referred to (IIUC) as being totalview-like:
> 
>     http://sourceware.org/ml/gdb/2008-08/msg00169.html

Yes, sort of.  itsets as stan described are just basically HPD's ptsets:

  http://sourceware.org/frysk/documentation/hpd.pdf

In fact, a lot of what's described in Stan's spec is HPD influenced.  Totalview
has similar concepts, and, it also has concept of something like dynamic
thread control groups.  See:

 http://www.totalviewtech.com/support/documentation/totalview/index.html

 Using Threads Processes and Threads
    Types of Threads
        Organizing Chaos

Note that given that non-stop controls threads individually, these
groups *can be implemented on the frontend side*, so this isn't really
*the* high priority to me.  Yes, I do think it is a nice feature to
have on the cli as well.

> 
> (The wiki should link to this note IMO... perhaps I will edit it in.)

Sure, go ahead.

> 
> Doug> I wonder what the normal usage pattern will be of multiprocess debugging.
> 
> Doug> An alternative to "set scheduler-multiple on|off" is to add another
> Doug> flag to the various commands.
> Doug> "scheduler-multiple" may be The Right Thing To Do, but adding more
> Doug> global state that controls command behaviour gives me pause
> Doug> ("exec-direction" anyone?).
> 
> I agree.  Global settings seem particularly user-unfriendly when
> debugging multiple inferiors.  E.g., what if you want to reverse-debug
> one inferior but none of the others?  I suppose you can make the
> settings per-inferior.  But this also seems to have potential for a
> lot of user confusion.
> 
> Doug> Another way to add scheduler-locking would have been to add
> Doug> options to "step", etc.  "s -l" or some such ["l" for "locking"
> Doug> though "locking" out of place here, it's just an example
> Doug> anyway].
> 
> Yeah.

Re. 'c -t 1 2 3', and similars, you're skipping a lot of ground.
The current all-stop design is very limited run-control wise, and
doesn't allow all those sorts of things.  E.g., the current target_resume
interface (and all the proceed/resume design) is limited in that you have to
tell the target what you want to resume in only a single call (think remote
protocol vCont --- as soon as you tell the target
to resume whatever, the target won't accept any other commands until something
stops).  I've mentioned before that gdb's resume interface would probably
benefit from reusing gdb's gdbserver target_resume interface ideas.  We'd
probably need to implement support for "held threads" as well, which by
itself is a good idea in the long run.  This is all a non-short
amount of work.

Non-stop, however, avoids all these issues by working on top
of an asynchronous target interface.  Unfortunatelly, I haven't
seen any effort in making all targets implement asynchronous
interfaces, or fixing the known async issues.  Until someone
tackles those items, we can't think of adding those "s -t 1 2 3"'s in
all-stop.  non-stop is a different issue.

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).

-- 
Pedro Alves