Re: [RFC] 07/10 non-stop inferior control

[Vladimir Prus <vladimir@codesourcery.com>]

Pedro Alves wrote:

> This patch adds the inferior control support for non-stop mode.
> 
> In non-stop mode, each thread is handled individually.  It should
> be like you have a separate debugger attached to each thread.
> To accomplish that, as soon as we have an event, we context switch
> to it, and go on handling it.  The cases of hiting a breakpoint
> in another thread while we're stepping don't need to be handled
> specially, as the stepping thread will have its state, and the
> other thread will have its own state.
> 
> Every exec command should apply only to the selected thread.
> 
> A new target_stop_ptid method was added to request the target
> to interrupt a single thread.
> 
> Several checks have been added so GDB doesn't try to do
> things with running threads, which don't make sense,
> like asking for the current PC of a running thread.
> 
> Info threads now shows the running state of a thread.  MI
> support can be added on top.
> 
> (gdb) info threads
> 3 Thread 0xf7603b90 (LWP 23454)  (running)
> * 2 Thread 0xf7e04b90 (LWP 23453)  0xffffe410 in __kernel_vsyscall ()
> 1 Thread 0xf7e056b0 (LWP 23450)  (running)

Am I missing something, or there's no way to interrupt all threads?
Given that we have "continue -a"/"-exec-continue --all", I think a way
to interrupt all threads will be desirable. In fact, I'd claim that if 
MI frontend has to issue several -exec-interrupt commands to stop the
program completely, it's a regression in functionality. Of course, I
can make MI do anything, but I need backend support for that :-)

Also, it seems inconsistent to me that "continue" has the -a option,
to resume all threads, while "interrupt" accepts an thread id. I'd
suggest that "interrupt" be modified to accept -a, and not accept
thread number. Or, alternatively, both continue and interrupt accept
both -a and thread number.

- Volodya