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

[Frédéric Riss]

> On Nov 7, 2014, at 10:28 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:
> 
> On 11/7/2014 12:25 PM, Frédéric Riss wrote:
>>> On Nov 7, 2014, at 10:07 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>>> 
>>> Thanks for your reply, Fred.
>>> 
>>> It might work better, if its in a form of an API. So that the linker could call an API instead of running a tool ?
>> Yes, the long term goal would be to expose it as an API. The separate tool is just a first step. I can’t give you the exact shape of the API know, but basically the main entry point would be something like:
>> 
>> DwarfLinker::link(const DebugMap& map);
>> 
>> Where the DebugMap is a collection of object files containing debug info associated with symbol mappings. In the end the dsymutil utility should just be a thin command line wrapper around that.
> Should this tool and the API exist as part of lld itself ? because linker is the only thing that calls it ?

We discussed this internally and changed minds a few times. The debate isn’t settled and I am still open to opinions (but I will stop changing my code coding conventions back and forth until we reach an agreement :-)). My current take on it is that if the tool end up as just a thin wrapper around libDebugInfo (+ maybe some other libs depending on how we do the streaming), then there is little point in hosting it with lld. As a matter of fact, the tool doesn’t use lld concepts at all and I’m pretty confident that there would be zero code sharing with lld.

Moreover, it is our long term goal to integrate the functionality in lld  (by linking lld with the library that provides the functionality), but today the linker never calls dsymutil. The clang driver does call it on darwin platforms when it generates temporary object files though, which IMO is another argument for having the utility hosted in LLVM proper.

Fred

> Shankar Easwaran
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
>