llvm dev - Nov 2014 - [LLVMdev] Reimplementing Darwin's dsymutil as an lld helper

> 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.
> On 11/7/2014 11:53 AM, Frédéric Riss wrote:
>>> On Nov 7, 2014, at 9:20 AM, Shankar Easwaran <shankare at
codeaurora.org> wrote:
>>> 
>>> Hi Fred,
>>> 
>>> Could this tool be extended to read DWARF information in the final
image and then pack it differently for other architectures as well ?
>> I guess it could, depending on what you exactly mean by “pack it
differently”. It could certainly strip some parts, or merge it with other file’s
debug information (But I’m not sure why you’d do that on a fully linked binary).
> I meant pack it differently for de-duplication.
I see. Just in order to reduce the debug info size. I /think/ it should be
possible to apply some of dsymutil’s optimizations to a linked dwarf binary.
It’s outside of the scope of what I plan to do for the initial implementation,
but it should be possible to reus of the code to implement that. I can
definitely try to keep that usecase in mind when I write the code though.

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

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 ?

Shankar Easwaran

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

> 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
>