Re: Non-stop multi-threaded debugging

[Vladimir Prus <vladimir@codesourcery.com>]

On Thursday 29 November 2007 20:36:18 Pawel Piech wrote:
> Vladimir Prus wrote:
> > On Thursday 29 November 2007 19:39:18 Pawel Piech wrote:
> >
> >   
> >>  I don't believe that I suggested adding any new command.
> >>  Instead, I suggested only changing the behavior of 
> >>  some of the existing commands to use the currently selected thread.
> >>  It was Jim's proposal that included adding new commands.
> >>  My point was that instead of adding new commands it would be cleaner
> >>  to extend the functionality of -thread-select in order to select 
> >>  a process context, i.e. a context that includes all threads. 
> >>  This way existing commands, which currently can only operate
> >>  on a global context, could now operate on a process or a thread context.        
> >>     
> >
> > Ok, we have those choices:
> >
> > 1. Make -exec-continue work on all threads, until -thread-select is used.
> > 2. Make -exec-continue work on one thread, and add another command
> > to operate on all threads.
> > 3. Make -exec-continue still operate on all threads, unless
> > and explicit option to make it operate on a thread is given.
> >
> > You've indicated that (1) and (3) are about the same in complexity for you --
> > am I right? 
> This is correct.
> > I personally prefer (3), since it does not implicitly changes
> > the meaning of existing commands.
> >
> > Surely, non-stop mode does require some changes in frontend, but the
> > fewer changes are, the better, IMO.
> >
> > - Volodya
> >   
> 
> In that case I'll try to convince you otherwise :-)
> 
> -exec-continue is not the only command that would need to be modified.  
> -exec-interrupt, would all need to take the -p parameter, and in order 
> to implement multi-process debugging, many of the commands that 
> currently operate on a global context (too many to try to list) would 
> all require an additional parameter to specify which process they are to 
> act on.  There seems to be a well established paradigm in the MI (and 
> CLI) protocol, where special commands: -thread-select and 
> -stack-frame-select change the state of the protocol so that commands 
> following these operate on the context selected by these commands.  

There are different opinions about those commands ;-) For example, I believe
that stateless protocol would be much easier.

> My  
> main point is to extend the functionality of these state-changing 
> commands in order to add the ability to select an active context, and to 
> select a context which will allow commands to operate on all the threads 
> of a process. 
> 
> IMO, the question of whether -exec-continue takes a -p argument is a 
> rather minor one.  But for sake of consistency with other -exec-* 
> commands I think it would be a mistake to add this parameter.  That's 
> because the stepping commands already do operate on the currently 
> selected thread.  While all the threads are resumed when stepping, 
> execution does not stop until the next line of code is reached by the 
> thread that was selected.  With non-stop debugging, stepping commands 
> will continue to operate on the selected thread with the difference that 
> other suspended threads will remain suspended.  

Interesting. Presently, in CLI gdb set 'scheduler mode' that controls
if step resumes all thread, or not. MI does not have a counterpart of that.
Maybe, we should start by changing -exec-step to accept a thread parameter, too,
which would mean "step only this thread, keep others suspended". Then,
-exec-continue taking thread parameter will be quite consistent with -exec-step.
I would say such change to -exec-step will be valuable in itself.

- Volodya