This resolves 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.
This should be removed, see comments below about having lldb_private::Section objects tracking if they have been relocated or not.