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 <[email protected]> wrote:
> On 10 December 2013 14:21, Ed Maste <[email protected]> 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.
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
