Regarding the overlapping files -- when lldb first loads multiple binaries (but
does not have a running process), it doesn't know where to set the load
addresses of these binaries so they are all 0-based (or if they have a
specified load address in the object file, at that address).
We rely on the dynamic linker on the system to tell us where libc.so is, and
then we update the target's section load list with that address.
For macos kernel debugging, we have a DynamicLoaderDarwinKernel that knows how
to load all the modules ("kexts") at the correct addresses for the program.
The user can also do this manually in command line lldb, like
target modules add <name of binary>
target modules load -f <name of binary> -s <slide to be applied to the load
address>
but it is correct behavior that in the absence of being told where the binaries
are loaded in memory, lldb will load them all at their base address, often 0 in
the modern days of pic code.
I haven't looked at the patch, but a long time ago I did hack that sounds
similar to yours for gdb, where I would assign binaries random addresses until
we had connected to a live process & learned where they should be. So address
-> symbol resolution would work. It never worked great and we decided to avoid
doing that in lldb.
> On Sep 20, 2017, at 3:41 PM, Koropoff, Brian via lldb-commits
> <lldb-commits@lists.llvm.org> wrote:
>
> Greetings. I'm submitting a few patches that resolve issues I
> encountered when using lldb to symbolicate FreeBSD kernel backtraces.
> The problems mostly centered around FreeBSD kernel modules actually
> being relocatable (.o) ELF Files.
>
> The major problems:
>
> - Relocations were not being applied to the DWARF debug info despite
> there being code to do this. Several issues prevented it from working:
>
> * Relocations are computed at the same time as the symbol table, but
> in the case of split debug files, symbol table parsing always
> redirects to the primary object file, meaning that relocations
> would never be applied in the debug file.
>
> * There's actually no guarantee that the symbol table has been
> parsed yet when trying to parse debug information.
>
> * When actually applying relocations, it will segfault because the
> object files are not mapped with MAP_PRIVATE and PROT_WRITE.
>
> - LLDB returned invalid results when performing ordinary
> address-to-symbol resolution. It turned out that the addresses
> specified in the section headers were all 0, so LLDB believed all the
> sections had overlapping "file addresses" and would sometimes
> return a symbol from the wrong section.
>
> I rearranged some of the symbol table parsing code to ensure
> relocations would get applied consistently and added manual calls to
> make sure it happens before trying to use DWARF info, but it feels
> kind of hacky. I'm open to suggestions for refactoring it.
>
> I solved the file address problem by computing synthetic addresses for
> the sections in object files so that they would not overlap in LLDB's
> lookup maps.
>
> With all these changes I'm able to successfully symbolicate backtraces
> that pass through FreeBSD kernel modules. Let me know if there is a
> better/cleaner way to achieve any of these fixes.
>
> --
>
> Brian Koropoff
> Dell EMC
> <0001-ObjectFile-ELF-use-private-memory-mappings.patch><0002-ObjectFile-ELF-ensure-relocations-are-done-for-split.patch><0003-SymbolFile-DWARF-force-application-of-relocations.patch><0004-ObjectFile-ELF-create-synthetic-file-addresses-for-r.patch>_______________________________________________
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
