This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: gdb7.2 - remote target - non-stop, multi-thread, target-async - non "OK" response, why?
- From: Pedro Alves <pedro at codesourcery dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Daniel Lehne <daniel dot lehne at amk-drives dot bg>, gdb-patches at sourceware dot org
- Date: Fri, 1 Jul 2011 17:37:52 +0100
- Subject: Re: gdb7.2 - remote target - non-stop, multi-thread, target-async - non "OK" response, why?
- References: <201106301502.01537.pedro@codesourcery.com> <m37h82c8aa.fsf@fleche.redhat.com>
On Friday 01 July 2011 16:47:25, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
>
> Pedro> Here, GDB told GDBserver to switch to non-stop
> Pedro> off (QNonStop:1 would be on). You need to enable
> Pedro> non-stop _before_ connecting to the remote target,
> Pedro> not after.
>
> Why is this?
The remote protocol behaves differently in non-stop mode. E.g.,
in all-stop, vCont is like a synchronous RPC --- it
tells the target to resume, and reply back with the status
the target next stops with. In non-stop, you get an "OK" right
away in reply to vCont, and target stops are reported through
an on-the-side asynchronous notification mechanism (%Stop). Some
other packets behave different in non-stop, one of them, being
the initial '?' (status) packet.
Now, with some care, it should be possible to flip between the
modes after connecting. The QNonStop packet was designed with
that in mind.
Note that connecting in all-stop mode necessarily forces the
target to stop on its tracks. Connecting in non-stop mode is
designed in principle to be uninvasive, and leave threads
running if they were already running.
Another alternative, which is my preferred, is to always enable
the non-stop variant of the protocol if the target supports it,
and then implement the all-stop user visible behavior on top.
We'd need async on by default first, though...
--
Pedro Alves