This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> ... 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.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.
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.
So it seems that Jim's proposal would already change the existing behavior of -exec-continue and -exec-step commands.- Execution commands like '-exec-continue' and '-exec-step' shall resume only the selected thread, without affecting the other threads in the process.
At the user interface level:Which to me implies that -exec-continue and -exec-interrupt would act on a single thread, although this is contradicted by the other statement about -exec-interrupt.
- MI shall provide a command to stop all the threads in a given process, and a command to resume all stopped threads in a given process.
Cheers, Pawel
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |