Re: MI non-stop mode spec

[Pawel Piech <pawel.piech@windriver.com>]

Defining thread sets for purpose of synchronized run control is an often 
requested feature in multi core debugging.  IMO it would be easier for 
the MI client, if the "threadset" command would itself create a new 
thread id, which would then be selected with -thread-select.

Cheers,
Pawel

Nick Roberts wrote:
>  >...
>  > > 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.
>
>