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

[Alexander Yermolovich via llvm-commits]

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

I think it's a difference in functionality/complexity.
Debuginfod, https://sourceware.org/elfutils/Debuginfod.html, is a service with all the network protocols/complexity to retrieve packaged debug information from some server. 
The gnulink is more a kin to a dwp file. It resides next to the main binary, and tools processing main binary can find it using the .gnu_debuglink section. There is an explicit link, unlike the dwp file. There is no need to deal with HTTP(S)/ssh network protocols, etc. All the functionality is native to llvm. 1) read a section 2) load an object. Same as for .dwp file (minus step 1).

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