>...
> > If a new feature is added to a particular command, such as the deferred
> > breakpoints, that single service can be replaced, updated, or extended
> > as needed. While adding an option across all commands forces changes in
> > all services. There is a command factory mechanism in CDI-GDB to
> > abstract some protocol changes which deals with small changes to
> > individual commands based on the protocol version, which DSF-GDB is
> > probably going to have to adopt as well. But this mechanism wouldn't be
> > necessary if the evolution in the protocol was more concerned with
> > backward compatibility, especially in a case like this where the
> > protocol change is not really necessary.
>
> Yes, I was thinking that a centralised entity that actually sends or
> creates command can easily add --thread option.
I'm nnot sure exactly how it is proposed that non-stop mode should work but
rather than a --thread option, why not have a separate command that determines
which thread(s) the following commands would act on? Perhaps only the
execution commands, e.g run, next etc, would recognise this set. Using CLI
commands ;-) it could work something like this:
(gdb) threadset 2-4
would mean that
(gdb) continue&
would resume threads 2, 3 and 4
Unlike operations like print, It doesn't seem necessary for these commands to
select the thread/frame first.
Presumably you will be interested in implementing barrier points so there
could be further commands to hold and release threads, e.g.,
(gdb) hold 3
would mean that in the example above only threads 2 and 4 resumed
(gdb) release 3
would allow it to run again.
The command "threadset" on its own could show all the threads in the current
set and the commands "hold" and "release" on their own could show which threads
are currently held/released.
For the current mode of operation, Gdb would give
(gdb) threadset
all
(gdb) hold
none
(gdb) release
all
This would then provide a backward compatible way to use all the MI
execution commands.