[llvm-dev] Adding accelerator tables to existing linked DWARF files

[Fangrui Song via llvm-dev]

On 2020-02-28, Greg Clayton via llvm-dev wrote:
>I am looking to create a tool that can add Apple or DWARF5 accelerator tables to fully linked executables that contain DWARF. This will help us benchmark how much accelerator tables can improve the debugging experience as debuggers don't need to manually index all of the debug info during debugging.
Is it for ELF, Mach-O, wasm, COFF, or any of the combinations?

>Looking at how accelerator tables are currently emitted, they seem to be built up as DWARF is being created or linked, and then emitted using a subclass of DWARFEmitter. The only subclass if this right now that I see is one in dsymutil which ends up emitting everything using an AsmPrinter by eventually emitAppleAccelTable(...) from llvm/include/llvm/CodeGen/AccelTable.h.
>
>I spoke briefly with Shoaib on this subject and he suggested adding code to llvm-objcopy. I briefly looked through the code and from what I can tell, llvm-objcopy doesn't seem to have any DWARF abilities other than compressing DWARF sections. If we do add functionality to llvm-objcopy, are we ok pulling in DebugInfoDWARF and the LLVM object model? AFAICT the code for this tools has its own object file layer which doesn't match the full layer inside of LLVM (llvm::ObjectFile and DWARFContext). Also, no AsmPrinter objects are used in this codebase either.

llvm-objcopy supports various ad-hoc binary manipulation features where each feature does a very
simple task. Neither llvm-objcopy nor GNU objcopy knows DWARF. --strip-debug,
--compress-debug-sections, --add-gnu-debuglink and --only-keep-debug have "debug" in their names but
these features don't need to parse DWARF. (GNU objcopy has a --debugging but that only works for
a.out and coff, not elf).

Do we have a more suitable tool for such debugging functionality? dsymutil for ELF?

>Looking at lld sources, is seems to use the DebugInfoDWARF library to some extent already. Not sure if this tool uses the standard LLVM object model or has all of its own emitters. Does lld use AsmPrinter at all? I don't see any mention of it in there.

--gdb-index and diagnostics (line tables) use DebugInfoDWARF. I have a plan to implement .debug_names, which is similar to --gdb-index.

>dsymutil has a --update feature which seems to load all of the DWARF and pretend to link it all the while generating the new accelerator table data, but I fear using this would pull it way too much code (AsmPrinter, all targets required to load all object files types, the standard llvm object file model (not the lld or llvm-objcopy versions), targets, etc).
>
>My initial thoughts are:
>1 - load a DWARFContext and iterate through the DWARF and build accelerator table data
>2 - create the sections for the accelerator tables and either keep in memory or save to disk
>3 - call functions to add the newly created sections to the binary
>
>#1 should be easy as long as I can use a DWARFContext from DebugInfoDWARF.
>#2 might need to be re-implemented using something other than an AsmPrinter?
>#3 can use llvm-objcopy code if needed since it can add sections?
>
>Any advice on how this can or should be implemented would be appreciated from anyone with experience.
>
>Greg Clayton
>

>_______________________________________________
>LLVM Developers mailing list
>llvm-dev at lists.llvm.org
>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev