<div dir="ltr"><div>Thanks Greg for the suggestions, I'll start working on that and put up a patch when I have something working.</div><div><br></div>Even doing it this way though, I imagine we'll still want to be able to load debug info for standard libraries if we can find it. I'm guessing we can only call functions from the symbol table if we have the function spec provided elsewhere (i.e. from a header file) or we know exactly what the function arguments are (as was the case in lldb_private::InferiorCallMmap).<div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 3:47 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
this may not be so important if we choose the approach Greg suggests<br>
(which sounds like a good idea), but in any case, I wanted to say that<br>
I don't think that we should be depending on the debug symbols in libc<br>
for a basic functionality like this. I think it's not safe to assume<br>
that debug symbols will be available on every machine. And in any<br>
case, mmap is a public symbol in libc, so it should be possible to<br>
find it without debug symbols:<br>
$ objdump -T /lib/<a href="http://libc-2.20.so" target="_blank">libc-2.20.so</a> | grep mmap<br>
00000000000e3670 w DF .text 0000000000000024 GLIBC_2.2.5 mmap64<br>
00000000000e3670 w DF .text 0000000000000024 GLIBC_2.2.5 mmap<br>
<br>
What does objdump produce on your machine? If mmap is there, and lldb<br>
is not finding it then I think we should find out why... </blockquote><div><br></div><div>I'd like to not depend on the debug symbols, but we should definitely load them if we can find them (as we do when running locally). The symbol table is in the stripped .so (readelf -s or objdump -T show the symbol entries for mmap), but we're calling <span style="font-size:12.8000001907349px">SymbolFileSymtab::</span><span style="font-size:12.8000001907349px">FindFunctions which returns 0 because we don't have the full method info. When called from</span> lldb_private::InferiorCallMmap, it <span style="font-size:12.8000001907349px">seems like all we need is the base address which we could get that from the symbol table. </span><span style="font-size:12.8000001907349px">To support general function calls into those functions though, as far as I can tell we can't tell from the symbol table what arguments are required, only the base address. I haven't tested this yet but I'm hoping that if the system header file for that function is included we'll find the function spec in the target's debug info.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
cheers,<br>
pl<br>
<div class=""><div class="h5"><br>
<br>
On 30 April 2015 at 23:53, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
><br>
>> On Apr 30, 2015, at 3:36 PM, Robert Flack <<a href="mailto:flackr@gmail.com">flackr@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I've been looking into why expression evaluation is failing when targeting a remote Linux machine from Mac lldb host and it seems there are only 2 distinct problems remaining - both around memory allocation:<br>
>><br>
>> 1. Can't find symbol for mmap.<br>
>> 2. Once found, lldb is calling mmap with incorrect constant values for MAP_ANON.<br>
>><br>
>> For problem 1, the library being linked against (e.g. /lib/x86_64-linux-gnu/<a href="http://libc-2.19.so" target="_blank">libc-2.19.so</a>) is copied into a local module cache, but we don't copy the unstripped library in /usr/lib/debug/lib/x86_64-linux-gnu/<a href="http://libc-2.19.so" target="_blank">libc-2.19.so</a> (I'm assuming we can't call mmap from the symtab file given SymbolFileSymtab::FindFunctions returns 0). To avoid having to duplicate the symbol discovery (in Symbols::LocateExecutableSymbolFile) we should probably ask lldb-platform on the target to find the symbol files for the current target (I'm thinking Platform::ResolveSymbolFile looks like the right place).<br>
>><br>
>> For problem 2, we're building the argument list to mmap and the constant for MAP_ANON on macosx is 0x1000 whereas for linux it's 0x20. I'm not sure what the right way to fix this is, I could imagine asking Platform to allocate memory, but this would likely be an involved change, or perhaps being able to ask platform for various OS specific const values which would be hard-coded into it when built for the target.<br>
>><br>
> So we need to implement the allocate and deallocate memory packets in lldb-server. It seems we have it implemented in the client, but not in the server:<br>
><br>
> addr_t<br>
> GDBRemoteCommunicationClient::AllocateMemory (size_t size, uint32_t permissions)<br>
> {<br>
> if (m_supports_alloc_dealloc_memory != eLazyBoolNo)<br>
> {<br>
> m_supports_alloc_dealloc_memory = eLazyBoolYes;<br>
> char packet[64];<br>
> const int packet_len = ::snprintf (packet, sizeof(packet), "_M%" PRIx64 ",%s%s%s",<br>
> (uint64_t)size,<br>
> permissions & lldb::ePermissionsReadable ? "r" : "",<br>
> permissions & lldb::ePermissionsWritable ? "w" : "",<br>
> permissions & lldb::ePermissionsExecutable ? "x" : "");<br>
> assert (packet_len < (int)sizeof(packet));<br>
> StringExtractorGDBRemote response;<br>
> if (SendPacketAndWaitForResponse (packet, packet_len, response, false) == PacketResult::Success)<br>
> {<br>
> if (response.IsUnsupportedResponse())<br>
> m_supports_alloc_dealloc_memory = eLazyBoolNo;<br>
> else if (!response.IsErrorResponse())<br>
> return response.GetHexMaxU64(false, LLDB_INVALID_ADDRESS);<br>
> }<br>
> else<br>
> {<br>
> m_supports_alloc_dealloc_memory = eLazyBoolNo;<br>
> }<br>
> }<br>
> return LLDB_INVALID_ADDRESS;<br>
> }<br>
><br>
> bool<br>
> GDBRemoteCommunicationClient::DeallocateMemory (addr_t addr)<br>
> {<br>
> if (m_supports_alloc_dealloc_memory != eLazyBoolNo)<br>
> {<br>
> m_supports_alloc_dealloc_memory = eLazyBoolYes;<br>
> char packet[64];<br>
> const int packet_len = ::snprintf(packet, sizeof(packet), "_m%" PRIx64, (uint64_t)addr);<br>
> assert (packet_len < (int)sizeof(packet));<br>
> StringExtractorGDBRemote response;<br>
> if (SendPacketAndWaitForResponse (packet, packet_len, response, false) == PacketResult::Success)<br>
> {<br>
> if (response.IsUnsupportedResponse())<br>
> m_supports_alloc_dealloc_memory = eLazyBoolNo;<br>
> else if (response.IsOKResponse())<br>
> return true;<br>
> }<br>
> else<br>
> {<br>
> m_supports_alloc_dealloc_memory = eLazyBoolNo;<br>
> }<br>
> }<br>
> return false;<br>
> }<br>
><br>
> Then you call mmap yourself on the native machine in lldb-server instead of trying to know what enums will work.<br>
><br>
> We actually need to ask the PlatformLinux to run an allocate/deallocate memory and hand it a process. So we can add the following to lldb_private::Platform:<br>
><br>
> virtual bool<br>
> SupportsMemoryAllocation();<br>
><br>
> virtual lldb::addr_t<br>
> AllocateMemory (lldb_private::Process *process, size_t size, uint32_t permissions, Error &error);<br>
><br>
><br>
> virtual Error<br>
> DeallocateMemory (lldb_private::Process *process, lldb::addr_t ptr);<br>
><br>
> Then the lldb_private::Process can get the current platform and ask it if it supports allocating memory, and if so call the Platform::AllocateMemory()/Platform:: DeallocateMemory().<br>
><br>
> Then the PlatformLinux can "do the right thing" and use the right defines.<br>
><br>
>> Anyways, I wanted to send this out to see if anyone had any thoughts on either of these issues or was already working on them. I have verified (by hacking in the correct const values for linux and placing debug libs in a path where they will be found) that this fixes expression evaluation (and 14 tests start passing) for mac->linux debugging.<br>
>><br>
>> Thanks in advance for any suggestions,<br>
>> Rob<br>
><br>
> So my suggestion is to implement the memory allocation/deallocation in lldb-server since it runs natively and will avoid the problems we run into by trying to evaluate functions by calling them remotely using #define values from the current system...<br>
><br>
><br>
>><br>
>> P.S. the 14 tests passing mac->linux by fixing this (for other people looking at cross platform tests):<br>
>> Test11588.py<br>
>> TestAnonymous.py<br>
>> TestBreakpointConditions.py<br>
>> TestCPPStaticMethods.py<br>
>> TestCStrings.py<br>
>> TestCallStdStringFunction.py<br>
>> TestDataFormatterCpp.py<br>
>> TestDataFormatterStdList.py<br>
>> TestExprDoesntBlock.py<br>
>> TestExprHelpExamples.py<br>
>> TestFunctionTypes.py<br>
>> TestPrintfAfterUp.py<br>
>> TestSBValuePersist.py<br>
>> TestSetValues.py<br>
>><br>
>> _______________________________________________<br>
>> lldb-dev mailing list<br>
>> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
</div></div></blockquote></div><br></div></div></div>