Please let me know if I'm missing something, as far as I can see
lldb-server does not have a Process object, only a NativeProcessLinux
(which is a NativeProcessProtocol). This doesn't seem to have the context
to run the thread plan to call malloc and allocate memory from lldb-server
- see the comment in NativeProcessLinux::AllocateMemory
and lldb_private::InferiorCallMmap / Process::RunThreadPlan for the full
details of what it needs to do. I'm not completely familiar with how the
interaction between lldb and lldb-server works, and I can try to implement
a function call with a NativeProcessLinux (preserving the previous state)
but it seems like this will be reimplementing a lot of functionality to do
so naively. Any thoughts? Is there a simple way to call malloc in the
context of the NativeProcessLinux and get the return that I'm missing?
On Fri, May 1, 2015 at 2:27 PM, Greg Clayton <gclay...@apple.com> wrote:
>
> > On May 1, 2015, at 7:00 AM, Robert Flack <fla...@gmail.com> wrote:
> >
> > Thanks Greg for the suggestions, I'll start working on that and put up a
> patch when I have something working.
> >
> > 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).
>
> mmap is a symbol every app needs to be able to link to. We don't need
> debug info to call it. We just need to be able to find the symbol for it so
> we know where the code for mmap is.
>
> > On Fri, May 1, 2015 at 3:47 AM, Pavel Labath <lab...@google.com> wrote:
> > Hi,
> >
> > this may not be so important if we choose the approach Greg suggests
> > (which sounds like a good idea), but in any case, I wanted to say that
> > I don't think that we should be depending on the debug symbols in libc
> > for a basic functionality like this. I think it's not safe to assume
> > that debug symbols will be available on every machine. And in any
> > case, mmap is a public symbol in libc, so it should be possible to
> > find it without debug symbols:
> > $ objdump -T /lib/libc-2.20.so | grep mmap
> > 00000000000e3670 w DF .text 0000000000000024 GLIBC_2.2.5 mmap64
> > 00000000000e3670 w DF .text 0000000000000024 GLIBC_2.2.5 mmap
> >
> > What does objdump produce on your machine? If mmap is there, and lldb
> > is not finding it then I think we should find out why...
> >
> > 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).
>
> Agreed. We don't require them, but it will be nice to have them.
>
> > The symbol table is in the stripped .so (readelf -s or objdump -T show
> the symbol entries for mmap), but we're calling
> SymbolFileSymtab::FindFunctions which returns 0 because we don't have the
> full method info. When called from lldb_private::InferiorCallMmap, it seems
> like all we need is the base address which we could get that from the
> symbol table. 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.
>
> Again, if "mmap" can be looked up via:
>
> void *mmap_address = dlsym(..., "mmap");
>
> Then there must be a public symbol available in the libc.so. If LLDB
> doesn't see this, we need to fix that, even without debug symbols.
>
>
>
> >
> > cheers,
> > pl
> >
> >
> > On 30 April 2015 at 23:53, Greg Clayton <gclay...@apple.com> wrote:
> > >
> > >> On Apr 30, 2015, at 3:36 PM, Robert Flack <fla...@gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> 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:
> > >>
> > >> 1. Can't find symbol for mmap.
> > >> 2. Once found, lldb is calling mmap with incorrect constant values
> for MAP_ANON.
> > >>
> > >> For problem 1, the library being linked against (e.g.
> /lib/x86_64-linux-gnu/libc-2.19.so) is copied into a local module cache,
> but we don't copy the unstripped library in
> /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so (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).
> > >>
> > >> 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.
> > >>
> > > 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:
> > >
> > > addr_t
> > > GDBRemoteCommunicationClient::AllocateMemory (size_t size, uint32_t
> permissions)
> > > {
> > > if (m_supports_alloc_dealloc_memory != eLazyBoolNo)
> > > {
> > > m_supports_alloc_dealloc_memory = eLazyBoolYes;
> > > char packet[64];
> > > const int packet_len = ::snprintf (packet, sizeof(packet),
> "_M%" PRIx64 ",%s%s%s",
> > > (uint64_t)size,
> > > permissions &
> lldb::ePermissionsReadable ? "r" : "",
> > > permissions &
> lldb::ePermissionsWritable ? "w" : "",
> > > permissions &
> lldb::ePermissionsExecutable ? "x" : "");
> > > assert (packet_len < (int)sizeof(packet));
> > > StringExtractorGDBRemote response;
> > > if (SendPacketAndWaitForResponse (packet, packet_len,
> response, false) == PacketResult::Success)
> > > {
> > > if (response.IsUnsupportedResponse())
> > > m_supports_alloc_dealloc_memory = eLazyBoolNo;
> > > else if (!response.IsErrorResponse())
> > > return response.GetHexMaxU64(false,
> LLDB_INVALID_ADDRESS);
> > > }
> > > else
> > > {
> > > m_supports_alloc_dealloc_memory = eLazyBoolNo;
> > > }
> > > }
> > > return LLDB_INVALID_ADDRESS;
> > > }
> > >
> > > bool
> > > GDBRemoteCommunicationClient::DeallocateMemory (addr_t addr)
> > > {
> > > if (m_supports_alloc_dealloc_memory != eLazyBoolNo)
> > > {
> > > m_supports_alloc_dealloc_memory = eLazyBoolYes;
> > > char packet[64];
> > > const int packet_len = ::snprintf(packet, sizeof(packet),
> "_m%" PRIx64, (uint64_t)addr);
> > > assert (packet_len < (int)sizeof(packet));
> > > StringExtractorGDBRemote response;
> > > if (SendPacketAndWaitForResponse (packet, packet_len,
> response, false) == PacketResult::Success)
> > > {
> > > if (response.IsUnsupportedResponse())
> > > m_supports_alloc_dealloc_memory = eLazyBoolNo;
> > > else if (response.IsOKResponse())
> > > return true;
> > > }
> > > else
> > > {
> > > m_supports_alloc_dealloc_memory = eLazyBoolNo;
> > > }
> > > }
> > > return false;
> > > }
> > >
> > > Then you call mmap yourself on the native machine in lldb-server
> instead of trying to know what enums will work.
> > >
> > > 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:
> > >
> > > virtual bool
> > > SupportsMemoryAllocation();
> > >
> > > virtual lldb::addr_t
> > > AllocateMemory (lldb_private::Process *process, size_t size,
> uint32_t permissions, Error &error);
> > >
> > >
> > > virtual Error
> > > DeallocateMemory (lldb_private::Process *process, lldb::addr_t
> ptr);
> > >
> > > 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().
> > >
> > > Then the PlatformLinux can "do the right thing" and use the right
> defines.
> > >
> > >> 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.
> > >>
> > >> Thanks in advance for any suggestions,
> > >> Rob
> > >
> > > 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...
> > >
> > >
> > >>
> > >> P.S. the 14 tests passing mac->linux by fixing this (for other people
> looking at cross platform tests):
> > >> Test11588.py
> > >> TestAnonymous.py
> > >> TestBreakpointConditions.py
> > >> TestCPPStaticMethods.py
> > >> TestCStrings.py
> > >> TestCallStdStringFunction.py
> > >> TestDataFormatterCpp.py
> > >> TestDataFormatterStdList.py
> > >> TestExprDoesntBlock.py
> > >> TestExprHelpExamples.py
> > >> TestFunctionTypes.py
> > >> TestPrintfAfterUp.py
> > >> TestSBValuePersist.py
> > >> TestSetValues.py
> > >>
> > >> _______________________________________________
> > >> lldb-dev mailing list
> > >> lldb-dev@cs.uiuc.edu
> > >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > >
> > >
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev@cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
