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

[Tom Tromey <tromey@redhat.com>]

>>>>> "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

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

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.

Doug> # This isn't implementable today, it's just for illustration.
Doug> define lstep
[...]

You can implement this with Python today :-) ...

Doug>   set $save_scheduler_locking [get scheduler-locking]

Here you use gdb.parameter.

Doug>   try

Python's try/catch works with gdb exceptions.

Tom