[Lldb-commits] [lldb] r196610 - Fixed the GDBRemoteCommuncation to return a new GDBRemoteCommuncation::PacketResult enum for all packet sends/receives.

[Greg Clayton]

Yes this is a QEMU GDB server bug.

The first packet that people normally send after attaching is the '?' packet, which wants a reply like the one you are getting, but there is nothing in any spec that I am aware of stating a stop reply packet must be sent as the first packet no matter what is sent to the GDB server.

We can probably modify the GDBRemoteCommunicationClient to get a packet immediately after sending the initial ack, to flush the GDB remote pipeline? 

So you can try this (see the 4 new lines immediately after the SendAck()):

bool
GDBRemoteCommunicationClient::HandshakeWithServer (Error *error_ptr)
{
    ResetDiscoverableSettings();

    // Start the read thread after we send the handshake ack since if we
    // fail to send the handshake ack, there is no reason to continue...
    if (SendAck())
    {
	// Wait for any responses that might have been queued up in the remote
        // GDB server and flush them all
	StringExtractorGDBRemote response;
	PacketResult packet_result = PacketResult::Success;
	const uint32_t timeout_usec = 10 * 1000; // Wait for 10 ms for a response
	while (packet_result == PacketResult::Success)
	    packet_result = WaitForPacketWithTimeoutMicroSecondsNoLock (response, timeout_usec);

	// The return value from QueryNoAckModeSupported() is true if the packet
        // was sent and _any_ response (including UNIMPLEMENTED) was received),
        // or false if no response was received. This quickly tells us if we have
        // a live connection to a remote GDB server...
        if (QueryNoAckModeSupported())
        {
            return true;
        }
        else
        {
            if (error_ptr)
                error_ptr->SetErrorString("failed to get reply to handshake packet");
        }
    }
    else
    {
        if (error_ptr)
            error_ptr->SetErrorString("failed to send the handshake ack");
    }
    return false;
}

On Dec 10, 2013, at 12:49 PM, Ed Maste <emaste at freebsd.org> wrote:

> On 10 December 2013 14:21, Ed Maste <emaste at freebsd.org> wrote:
>>> This actually does fix attaching to GDB servers that don't support QStartNoAckMode and was the main reason for making this fix!
>> 
>> Ok.  I'm trying to use lldb against QEMU's GDB server, and fail while
>> trying the initial handshake.
> 
> It seems there are a couple of issues here, at least one of which
> appears to be a QEMU bug.
> 
> On one instance, after restarting both QEMU and LLDB, I see:
> 
> (lldb) log enable gdb-remote packets
> (lldb) gdb-remote localhost:1234
> <   1> send packet: +
> history[1] tid=0x18c46 <   1> send packet: +
> <  19> send packet: $QStartNoAckMode#b0
> <  17> read packet: $T02thread:01;#04
> <   1> send packet: +
> error: failed to get reply to handshake packet
> 
> and indeed, a telnet to :1234 shows QEMU outputs "$T02thread:01;#04"
> without any input from the client, so the unexpected received packet
> was just waiting in the input buffer.  Retrying
> QueryNoAckModeSupported (once) if it fails is successful as a hack /
> workaround.