Re: Non-stop multi-threaded debugging

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

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.  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.  It seems logical to me 
that -exec-continue and -exec-interrupt should operate in the same way.  
In the degenerate case where the target is not capable non-stop 
multi-threaded debugging, conceptually these commands can still be 
thought of as operating on the selected thread, with the side effect 
that when one thread is resumed/suspended, all threads are 
resumed/suspended as well.

Cheers,
Pawel