[LLVMdev] Reimplementing Darwin's dsymutil as an lld helper

[Rui Ueyama]

Seems I have no enough knowledge both on the Darwin-specific command and on
the debug info in general, but as far as I can tell I didn't see any red
sign. This is on my to-do list to bring DWARF support for ELF and for
PE/COFF to LLD, so I'm happy to see you have started working on the DWARF
support.

On Fri, Nov 7, 2014 at 8:09 AM, Frédéric Riss <friss at apple.com> wrote:

> Hi,
>
> [ I Cc'd lld people and debug info people. Apologies if I omitted some
> stakeholder. ]
>
> As stated in the subject, I’d like to start working on an in-tree
> reimplementation of Darwin’s dsymutil utility. This is an initial step on
> the path to having lld handle the debug information itself.
>
> For those who are not familiar with the debug flow on MacOS, dsymutil is a
> DWARF linker. Darwin’s linker (ld64) doesn’t link the DWARF debug info
> found in the object files, instead it writes a “debug-map” in the linked
> binary. This debug-map describes what objects were linked together and what
> atoms of each object file are present in the binary along with their
> addresses. The debug-map has two uses:
> 1) During the build->debug cycle, lldb reads the debug-map and uses it to
> find the .o files and extract the relevant dwarf debug info.
> 2) For Release builds, dsymutil reads the debug-map then loads, merges,
> and optimizes all the dwarf debug info and writes it as as a .dSYM
>
> The long term goal is that dwarf linking functionality be available as a
> library for LLVM tools. Eventually, we’d like lld to be able to make use of
> the dwarf linking library and not need a stand along dsymutil tool.  The
> first step is to use the dwarf linking library in a stand along dsymutil
> replacement tool. We want this tool to be bit-for-bit compatible with the
> existing Darwin dsymutil.
>
> The main reason we want to take the first step of a separate tool is
> testability. The code committed to the LLVM repository will feature unit
> tests, but they won’t offer the coverage that a real world usage would. I
> plan to run the new tool through big internal validation campaigns during
> which the llvm powered dsymutil output would be compared to the system’s
> dsymutil one. This is also the reason we aim for bit-for-bit compatibility.
>
> The current plan is to host the code in the llvm repository. dsymutil will
> make heavy use of libDebugInfo and won’t share anything with the lld
> codebase (The underlying concepts are just too different). It’s also not
> clear yet where most of the implementation logic will end up. I expect most
> of the core logic to be in tools/dsymutil, but some of it might be better
> folded directly into libDebugInfo.
>
> So how does it work? dsymutil doesn’t simply paste the debug sections
> together while applying relocations to them. This wouldn’t work for ld64 as
> it is able (like lld) to split the sections apart and discard/reorder the
> contents. Thus dsymutil needs some semantic knowledge of the DWARF contents
> to be able to “patch” the relocatable debug info with accurate values. It
> is also able to remove parts of the DIE tree that aren’t needed or to
> unique types across the compilation unit boundaries. In libDebugInfo, we
> have the needed tooling to read the debug info, but we currently lack the
> ability to write it back to disk. Maybe what’s in lib/CodeGen/AsmPrinter to
> emit the debug info would fit the bill, but I won't be sure until I try to
> write the code. I’ll see along the way if libDebugInfo should grow it’s own
> Dwarf streaming capabilities. Opinions welcome.
>
> Although the implementation of the dsymutil command line tool will be
> fairly Darwin specific (it accepts mach-o files as input and emits a dSYM
> bundle), most of the implementation will be format agnostic. I’ll make an
> effort to split the mach-o specific parts into their own files so that this
> code can be reused in a generic way. Would there be interest in that kind
> of code for other platforms also? What’s the story of lld Dwarf support for
> ELF?
>
> I plan on sending the initial code (that does basically only parse the
> debug map of mach-o files) out for review in the coming days if there are
> no objections to the general principle.
>
> Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141107/71dd9303/attachment.html>