RFA: non-stop/linux, thread stopping

[Pedro Alves]

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 ?

-- 
Pedro Alves
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nonstop_stop.diff
Type: text/x-diff
Size: 21062 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20081016/704d1337/attachment.bin>