[llvm] [LLVM][DWARF] Add support for .gnu_debuglink (PR #77715)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> > @kevinfrei since you just posted some debuginfod work (#78605) I'm tagging you in here (though perhaps @petrhosek has some thoughts/other folks that'd want to be involved)
> > Seems like between debuginfod and gnu_debuglink - those are at least two ways to lookup the original binary with debug info given a stripped binary, and we should have some unified way/place that attempts these various resolution options.
> > Ah, I think I see why you're adding the GnuLink member (now that I see it has no usage, it's only a lifetime issue) - because usually the lifetime of the object is managed by the caller of DWARFContext::create, but because create is opening a new object it has to preserve the object's lifetime longer.
> > I think I'd still rather see that not affect DWARFContext's members - for instance, DWARFContext::create could take a non-const reference to `object::OwningBinary<object::ObjectFile>` and replace it with the linked object.
> > Or it could be a separate function - possibly exposed by DWARFContext (but I know you want something to be a drop-in replacement for all DWARFContext usage & this wouldn't provide that) that takes the OwningBinary/ObjectFile and remaps it, if necessary, to the linked debug info (gnu_debuglink, debuginfod, or whatever else).
> 
> Debuginfod is a service to acquire symbols/source from a repository, while the .gnu.debuglink is a way to connect a stripped binary file with it's corresponding debug info (with a _different_ CRC for verification :/ ). Debuginfod uses _only_ the .note.gnu.build-id to connect files. They're not completely separate, but I don't think making a "debuglink" SymbolLocator plugin makes any sort of sense, while it's a very rational design for interacting with Debuginfod. I am, however, fairly new to the space (my background is compilers) so I'm definitely open to learning what I'm missing...

Not sure I understand... - for arguments sake, lets say debuglink only lets you find a only-keep-debug binary (say, using this as a model: https://help.totalview.io/previous_releases/2019/HTML/index.html#page/Reference_Guide/Usinggnu_debuglinkFiles.html ). So debuglink lets you find the only-keep-debug binary.

Debuginfod lets you find the unstripped binary, yeah? (among other things)

So, for the purposes of this library (libDebugInfoDWARF) those two things are equivalent - these tools only look at the debug sections. So from this perspective, these actions (debuginfod finding/retrieving an unstripped binary, and debuglink finding a only-keep-debug binary) are equivalent - two different ways of achieving the same end, getting the debug info sections.

I think? Perhaps I'm misunderstanding something of these two tools.

https://github.com/llvm/llvm-project/pull/77715