Fix a gdbremote bug in _M/_m stub support detection.
When a stub reported $#00 (unsupported) for _M and _m
packets, the unsupported response was not handled and
the client then marked the _M/_m commands as definitely
supported. However, they would always fail, preventing
lldb's fallback InferiorCallMmap-based allocation strategy
from being used to attempt to allocate memory in the inferior
process space.
llvm-svn: 211425
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
index 4ba2ca1..f7beac2 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -1881,7 +1881,9 @@
StringExtractorGDBRemote response;
if (SendPacketAndWaitForResponse (packet, packet_len, response, false) == PacketResult::Success)
{
- if (!response.IsErrorResponse())
+ if (response.IsUnsupportedResponse())
+ m_supports_alloc_dealloc_memory = eLazyBoolNo;
+ else if (!response.IsErrorResponse())
return response.GetHexMaxU64(false, LLDB_INVALID_ADDRESS);
}
else
@@ -1904,7 +1906,9 @@
StringExtractorGDBRemote response;
if (SendPacketAndWaitForResponse (packet, packet_len, response, false) == PacketResult::Success)
{
- if (response.IsOKResponse())
+ if (response.IsUnsupportedResponse())
+ m_supports_alloc_dealloc_memory = eLazyBoolNo;
+ else if (response.IsOKResponse())
return true;
}
else