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

[David Blaikie via llvm-dev]

On Mon, Mar 2, 2020 at 7:57 PM Greg Clayton <clayborg at gmail.com> wrote:

>
>
> On Mar 2, 2020, at 4:42 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
> Is there/could you further explain the use-case for adding an index to an
> existing binary? Certainly not the worst idea/could come in handy
> sometimes, but you mention benchmarking - is the benefit of not
> recompiling/relinking that significant to such experiments?
>
>
> It is hard to get people to adopt new toolchains into their workflows. So
> the idea here is to allow people to use what ever toolchains they want to
> to produce a binary, then add accelerator tables to their linked binaries
> so they can "try before you buy" kind of thing. It also allows accelerator
> tables to be updated in case there were bugs in older versions of the
> tools, or as new accelerator tables come out or newer versions are
> available. Once we prove that the accelerator tables are viable and worth
> it, we get people to want to migrate to newer toolchains that have this
> functionality built in.
>
>
> If it's not for use in a common workflow, but only in a compiler/debugger
> development workflow, it doesn't seem so important to me.
>
>
> It is for production workflows for people that are on older toolchains and
> are not able to upgrade for stability to business purposes. So it isn't
> just for compiler/debugger development.
>

Fair enough - thanks for the framing!


>
>
> On Mon, Mar 2, 2020 at 3:50 PM Greg Clayton via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> We could specify ELF support for the --update feature only for now, which
>> adds the accelerator tables adding support. For full linking to work, we
>> will need some sort of ELF specific of stand alone debug map file that can
>> be read for real linking, though that won't be too hard.
>>
>
> Not sure I follow here - --update would be given a fully linked binary,
> yes? So why would it need a debug map?
>
>
> It wouldn't. If you take a look at the dsymutil code though, they did some
> hackery to make it pretend like it is relinking the DWARF. So no debug map
> is needed, but dsymutil will run it through the same kind of machinery. But
> that being said, it would be very easy to repurpose this code to take a
> linker map for ELF and become the linker for DWARF in .o files in LLD
> (where it does smart linking, not just concatenate and relocate like most
> linkers currently do).
>

Yeah, that work's already being done, by the sounds of it (using
DwarfLinker (the implementation of dsymutil) in lld for ELF and such).


>
>
> It'd have the debug info & the linked executable code available, so you'd
> be able to see which bits of the executable code are referred to by which
> bits of debug info.
>
>
> --update was in the original dsymutil that I wrote and it would just
> update the accelerator tables in the dSYM file and rewrite the binary and
> exit. There were a few iterations of the accelerator tables and this
> allowed us to quickly update older and out of date versions. The
> llvm-dsymutil has this feature and also allows you to specify DWARF5 or
> Apple accelerator tables.
>

Ah, good to know there's precedent there, then.

Sounds like you've got the right people involved/signing off on the
dsymutil direction - so I'll leave you folks to it!

- Dave


>
>
>
>
>>
>> On Mar 2, 2020, at 3:44 PM, Eric Christopher <echristo at gmail.com> wrote:
>>
>> I'd like it... Adrian? Fred?
>>
>> -eric
>>
>> On Mon, Mar 2, 2020 at 3:44 PM Greg Clayton <clayborg at gmail.com> wrote:
>>
>>> Yes. I am fine with adding ELF support to llvm-dsymutil if that is the
>>> way people think we should go?
>>>
>> Feels like a bit of a weird fit to me (equally llvm-objcopy seems like a
> weird fit too) - given the specific name & nature of Darwin debug info
> distribution being a bit different (reading object files, having input from
> the linker, etc) & the specific name being pretty uniquely applied to that
> model/output.
>
> (does that way lie moving dwp functionality to llvm-dsymutil too? )
>
> But don't feel super strongly about any of it.
>
>
> I'd be fine with making a new "llvm-dwarfld" tool if we think that is the
> way to go. The main issue is there would be a lot of duplicated code
> between llvm-dsymutil and llvm-dwarfld.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200303/53300478/attachment.html>