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

[Greg Clayton via llvm-dev]

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

> 
> On Mon, Mar 2, 2020 at 3:50 PM Greg Clayton via llvm-dev <llvm-dev at lists.llvm.org <mailto: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).


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


>  
> 
>> On Mar 2, 2020, at 3:44 PM, Eric Christopher <echristo at gmail.com <mailto: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 <mailto: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/20200302/cac2a42d/attachment.html>