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
This commit is contained in:
Todd Fiala 2014-06-21 00:48:09 +00:00
parent d119fa028a
commit f105f588b3
1 changed files with 6 additions and 2 deletions

View File

@ -1881,7 +1881,9 @@ GDBRemoteCommunicationClient::AllocateMemory (size_t size, uint32_t permissions)
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 @@ GDBRemoteCommunicationClient::DeallocateMemory (addr_t addr)
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