[Lldb-commits] [lldb] r196610 - Fixed the GDBRemoteCommuncation to return a new GDBRemoteCommuncation::PacketResult enum for all packet sends/receives.
gclayton at apple.com
Tue Dec 10 12:58:25 PST 2013
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()):
GDBRemoteCommunicationClient::HandshakeWithServer (Error *error_ptr)
// 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...
// Wait for any responses that might have been queued up in the remote
// GDB server and flush them all
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...
error_ptr->SetErrorString("failed to get reply to handshake packet");
error_ptr->SetErrorString("failed to send the handshake ack");
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 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 /
More information about the lldb-commits