Hi,

I ended up making a tiny adjustment to make this mostly affect non-stop
mode only, hence making it much less likely to cause allround breakage.

I then re-tested on x86-64-unknown-linux-gnu (-m64/-m32), and checked
it in.  Please find attached what went in.

-- 
Pedro Alves

On Thursday 16 October 2008 03:54:38, Pedro Alves wrote:
> Hi all,
> 
> [ Yet another patch preparing for remote non-stop.  ]
> 
> While designing the remote non-stop protocol, and the
> "interrupt", "interrupt -a" support, we came up with a new vCont
> extension, `vCont;t', or applied to a thread, `vCont;t:TID',
> meaning, roughly:
> 
> "stop/suspend the target thread TID, however you can and feel like.
> If nothing interesting happens to the thread while stopping it, then report
> back a TARGET_SIGNAL_0, because I don't care how the thread was
> suspended behind the scenes.  You take care of it."
> 
> This takes advantage of the fact that TARGET_SIGNAL_0 is defined as:
> 
>  src/include/gdb/signal.h:
> 
>     /* Used some places (e.g. stop_signal) to record the concept that
>        there is no signal.  */
>     TARGET_SIGNAL_0 = 0,
> 
> When implementing this on gdbserver (ptrace/linux), this effectivelly
> translated into stopping an LWP with SIGSTOP, nicelly moving away
> from SIGINT, process groups, shared or not-shared signal queues
> and the like.
> 
> Another propertly of `vCont;t', is that it is defined as doing
> nothing to already stopped threads.  This requirement (to not do
> anything to stopped threads), implies that threads that were
> already stopped due to internal events when an explicit stop
> is requested, most notably, threads that are stopped waiting for their
> turn in the displaced stepping queue (*), should remain stopped, and
> GDB should report that stop as if the target had done so
> itself.  That is, GDB should make the stop "public".
> 
> There are cases where this property is useful, and following
> patches will rely on it.
> 
> *) remember we only have one scratch space currently, so
> we can only ool-step one thread at a time.
> 
> This patch changes native linux non-stop to behave the same, and
> adds the necessary glue to the common code.
> 
> To make it nicer on the eye, I'm making an output change in
> the CLI:
> 
> New:
> 
>  [Thread 0xf7e306b0 (LWP 26335)] #1 stopped.
>  0xffffe410 in __kernel_vsyscall ()
> 
> Old:
> 
>  Program received signal 0, Signal 0.
>  0xffffe410 in __kernel_vsyscall ()
> 
> The old output is IMHO, very weird, as a program usually
> doesn't stop with a signal 0.  :-)  It also lacked information
> of which thread had stopped.
> 
> No MI changes are necessary.
> *stopped,reason="signal-received",signal-name="0" is still OK.
> 
> A frontend can then react accordingly to how the thread was stopped, and treat
> signal 0 specialy if it wants to:  Say, if it was a TARGET_SIGNAL_0, then just
> perhaps update the thread state icon in a thread tree view, by displaying
> a "pause" icon.  If it is was a SIGINT, SIGSEGV or some other signal, then
> popup a message box, for example.
> 
> How does this all sound?  I'm certain that handle_inferior_event will
> need a bit more tweaking here and there to acommodate corner cases, but
> I don't expect much.  The base principle is "if the thread had an
> explicit request to stop, then when we get a stop event, don't resume
> it automatically.".  That's all.
> 
> About the code changes themselves:
> 
>  - I'm using an observer to make two GDB components comunicate.
> 
>       thread.c -> infrun.c
> 
>  - ptid_is_pid: new function.  I must have written this function
>    5 times already, using 3 different idioms, across several files, but
>    I haven't contributed any of those.  Might as well make it to
>    common code, where it belongs.  It returns true if a ptid
>    represents a process.
> 
>  - This was the reason I had added mi_expect_interrupt instead of
>    reusing mi_expect_stop.  With this change, since no current target
>    will report a SIGINT on a -exec-interrupt, I can just make it only
>    recognize signal 0.
> 
> All-in-all, tested on x86-pc-linux-gnu.
> 
> Does it sound/look sane/OK ?
>