Re: Non-stop multi-threaded debugging

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

Vladimir Prus wrote:
> 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.
>
>   
I completely agree with you, for a "machine interface" a stateless 
protocol would be much easier to use.  But GDB/MI is what it is and at 
this point trying to make it stateless would probably be counter productive.
>> 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
>   
I'm rather confused here.  I thought that the point of non-stop 
multi-threaded debugging was to allow for this behavior.  Is "scheduler 
mode" some kind of partial implementation?  Either way though, I have no 
opinion whether it would be useful for the command line user to be able 
to specify the scheduling mode as an option to individual commands, but 
in an IDE such behavior would most likely be controlled with a toggle 
button, so a mode switch command would be sufficient.  If -exec-step 
would take a -p parameter to determine whether to resume all threads, 
then -exec-step without -p would still operate on the selected thread, 
in that it would suspend the process only when the selected thread 
reached the next line.  IHMO, this would only add to the confusion.

Cheers,
Pawel