RFA: non-stop/linux, thread stopping
Pedro Alves
pedro@codesourcery.com
Thu Oct 23 23:16:00 GMT 2008
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 ?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: non_stop_stop.diff
Type: text/x-diff
Size: 21328 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20081023/08351397/attachment.bin>
More information about the Gdb-patches
mailing list