Re: Non-stop multi-threaded debugging

[Pawel Piech <pawel dot piech at windriver dot com>]

Hello,
I am collaborating with Ericsson on implementing GDB support in Eclipse 
and I'm very much looking forward to seeing this functionality 
implemented in GDB.   With the Eclipse use of the MI protocol in mind I 
have a couple of comments and questions on the proposal:

> P1) Non-stop multi-threaded native debugging
<snip>
>     - The MI '-exec-interrupt' command shall stop all threads.  This
>       will always generate an 'EXEC-ASYNC-OUTPUT' record, even if all
>       threads were already stopped.  (This helps users handle the case
>       where the thread stops of its own accord just as the user sends
>       it an '-exec-interrupt' command.)
>
>     - The MI '-thread-select' command shall stop the thread selected,
>       if it is running.  The previously selected thread is left in its
>       former state, either stopped or running.  A '-thread-select'
>       command shall always generate an 'EXEC-ASYNC-OUTPUT' record,
>       even if the thread was already stopped.
I think using -thread-select to suspend a thread will have negative 
consequences to the MI-client.  The -thread-select is used to change the 
protocol state before requesting data related to that thread.  Adding 
the side-effect of suspending the thread, will force the client to add 
additional logic to avoid suspending threads accidentally as a result of 
attempting to read data.  I think it would be much safer to use an 
explicit -exec-interrupt request (after a -thread-select) to suspend a 
thread. 
Note that either way GDB will have to handle and return an errors to 
requests for data (such as stack or expressions) while a selected thread 
is running.  If a client sends a -exec-continue, I assume that whatever 
thread was selected last will still be selected.  So a 
-stack-list-frames should result in an error.

> P7) Non-stop multi-threaded multi-process native debugging
<snip>
>     - 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.

I would like to make a suggestion here.  Instead of inventing a new set 
of parallel commands and events to deal with process-wide events, it 
would be cleaner to simply assign thread IDs to processes and use 
existing commands and events to operate on them.  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.

While events could also be re-used to report without any changes to the 
event format, it would be very helpful for the client if the events 
included both the process's and thread's thread ID, as well as whether 
all threads stopped as the result of the event:
...
-thread-select 2
^done
-exec-interrupt
*stopped, thread-id="2", process-thread-id="1", all-threads="false", ....
^done
...
-thread-select 1
^done
-exec-continue
^running, thread-id="1", process-thread-id="1", all-threads="true"
...

Cheers,
Pawel