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

[Kevin Frei via llvm-commits]

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

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