Re: Non-stop multi-threaded debugging

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

Vladimir Prus wrote:
> Pawel Piech wrote:
>
>   
>> Nick Roberts wrote:
>>     
>>>  >                                           ... A -thread-select on an
>>>  > ID of a process followed by an -exec-continue would resume an entire
>>>  > process, while a -thread-select of a thread's ID followed by a
>>>  > continue
>>>  > would resume only that thread.  This could also be applied to all
>>>  > other commands that need to operate on a process, such as
>>>  > -thread-list-ids, -break-insert, etc.
>>>
>>> This would change the current behaviour of these commands.  If a new
>>> command is undesirable then perhaps optional parameters could be used:
>>>
>>>      -exec-continue [ -p THREAD-ID/PROCESS-ID ]
>>>      -exec-interrupt [ -p THREAD-ID/PROCESS-ID ]
>>>
>>> It appears that -break-insert already has such an option for threads.
>>>
>>>   
>>>       
>>  From Eclipse's point of view it actually doesn't make much difference
>> whether -thread-select or -p option is used to specify the thread.
>>
>> That said, I would argue that adding the non-stop debugging feature
>> changes the behavior of the entire system, so it could be expected that
>> some commands will behave somewhat differently as they relate to this
>> new feature.  Actually, with non-stop debugging feature turned off, and
>> without attaching to multiple processes, these commands would still
>> behave exactly as they do now.
>>     
>
> Given the choice between:
>
> 1. Changing the behaviour of the existing command, and adding new one
> that behaves like existing one, and
>
> 2. Adding new command
>
> I think adding new command (or option to existing command), is a smaller change.
> So yes, -exec-continue -t <xxx> might be a better choice.
>
> - Volodya
>   
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.

Cheers,
Pawel