Re: gdb7.2 - remote target - non-stop, multi-thread, target-async - non "OK" response, why?

[Pedro Alves <pedro at codesourcery dot com>]

[Please remember to keep the list in CC.]

On Thursday 30 June 2011 12:24:19, Daniel Lehne wrote:
> gdb log
> set debug remote 1
> set confirm on
> set verbose on
> target extended-remote 192.168.0.243:1234
> Remote debugging using 192.168.0.243:1234
> Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
> Packet received: 
> PacketSize=3fff;QPassSignals+;qXfer:libraries:read+;qXfer:auxv:read+;qXfer:spu:read+;qXfer:spu:write+;qXfer:siginfo:read+;qXfer:siginfo:write+;qXfer:features:read+;QStartNoAckMode+;qXfer:osdata:read+;multiprocess+;QNonStop+;qXfer:threads:read+
> Packet qSupported (supported-packets) is supported
> Sending packet: $QStartNoAckMode#b0...Ack
> Packet received: OK
> Sending packet: $!#21...Packet received: OK
> Sending packet: $Hgp0.0#ad...Packet received: E01
> Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet 
> received: E01
> Sending packet: $QNonStop:0#8c...Packet received: OK

Here, GDB told GDBserver to switch to non-stop
off (QNonStop:1 would be on).  You need to enable
non-stop _before_ connecting to the remote target,
not after.

> Sending packet: $?#3f...Packet received: W00
> set non-stop on

This is a GDB bug.  It should have thrown an error.
(infrun.c:set_non_stop checks for target_has_execution,
but since you've connected in extended-remote, there's
no execution yet.).

The end result was that GDBserver was in all-stop
mode, while GDB was in non-stop mode.  And that's why
you got:

> Sending packet: $vCont;c:pfba.fba#d2...Packet received: 
> T050b:44cbe1be;0d:c8c9e1be;0f:bcec0040;thread:pfba.fba;core:0;
> Unexpected vCont reply in non-stop mode: 

-- 
Pedro Alves