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

Doug Evans
2009-05-31T16:34:09Z

On Sat, May 30, 2009 at 3:51 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> Currently, with the generic framework, if GDB is attached to
> multiple processes, issuing a "continue", "next", etc., makes GDB
> resume all threads of all processes.  But, with the multi-forks
> framework, GDB only debugs one of the forks at a given time, while
> leaving the others stopped.

Except in non-stop mode when "c -a" is required to continue all
threads, "c" by itself just continues the current thread (right?).
[And IWBN if there were a way to continue a subgroup of threads though
I realize "c N" is already taken. "c [-a] [-t T1 T2 T3] [--] [N]"? I
realize that's perhaps not ideal, but short of adding another command
it's the first thing that came to me. :-) And no claim is made that
this hasn't been discussed before ...]

I wonder what the normal usage pattern will be of multiprocess debugging.

An alternative to "set scheduler-multiple on|off" is to add another
flag to the various commands.
"scheduler-multiple" may be The Right Thing To Do, but adding more
global state that controls command behaviour gives me pause
("exec-direction" anyone?). Another way to add scheduler-locking
would have been to add options to "step", etc. "s -l" or some such
["l" for "locking" though "locking" out of place here, it's just an
example anyway]. It's easier to script:

# This isn't implementable today, it's just for illustration.
define lstep
set $save_scheduler_locking [get scheduler-locking]
try
step
finally
set scheduler-locking $save_scheduler_locking
end
end

versus

define lstep
step -l
end

I'd be curious to hear what others think.