This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Non-stop multi-threaded debugging
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