Re: Non-stop multi-threaded debugging

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

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. 

In fact, the original post states:
>     - Execution commands like '-exec-continue' and '-exec-step' shall
>       resume only the selected thread, without affecting the other
>       threads in the process.
So it seems that Jim's proposal would already change the existing 
behavior of -exec-continue and -exec-step commands.


Also:
> At the user interface level:
>
>     - 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.
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.


Lastly, since my post I thought a little about the CLI aspect in my 
suggested use of thread IDs.  It would probably be a little awkward to 
use the "thread <id>" command to switch to a different process, or to 
use it with a process-id to initiate process-wide operations.  So for 
the CLI interface, while I still think it would make sense to use the 
same ID name-space for processes and threads, it would help to add a 
couple of new commands:

"process <id>" - To select a new active process where the active thread 
would be the last active thread in this process.  This would be the 
equivalent of a -thread-select with the last active thread in that process.

"thread all" - To un-select the current thread in order to perform 
operations on all threads in the process.  Equivalent of -thread-select 
with the ID of the process.

Cheers,
Pawel