[lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

Kevin Frei via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 2 09:55:48 PDT 2023


kevinfrei wrote:

> First off, thank you for working on this. `debuginfod` has been on my radar since support was added to LLVM and I was curious at which point someone was going to add support for it to LLDB. I wasn't super familiar with what exactly it provides, and in case others here aren't either, I found the following documentation very helpful: https://llvm.org/doxygen/Debuginfod_8h.html. TL;DR: it gives you a way to get sources, (symbol rich) executables and debug info files.
> 
> The functionality `debuginfod` offers seems very similar to `dsymForUUID` (see https://lldb.llvm.org/use/symbols.html). We have series of functions such as `LocateExecutableObjectFile` and `LocateExecutableSymbolFile` in `LocateSymbolFile.h` that abstract over this. It seems appropriate that we use the same abstractions for `debuginfod` which avoids the special casing this patch introduces and a lot of things will "just work".
> 
> The one caveat is that the current implementation is really tied to a platform. All the `dsymForUUID` stuff is implemented in `LocateSymbolFileMacOSX.cpp`. I think we might need to move this to a Plugin model where we can have multiple implementations. The plugin name `SymbolVendor` is already taken so I would call this the `SymbolServer` plugin. Converting the current model to a plugin should be done in separate patch and myself or other Apple folks can make sure this doesn't break the dsymForUUID paths (we have some tests but not enough given how critical this is for us). With that done, it should be trivial to add a plugin implementation that calls into `debuginfod`

Yes, that specific kind of refactoring seemed like a good idea, but given that this is my first real foray into the LLDB space, I didn't want to bite off that much work to start with. Once I've got the full DEBUGINFOD capabilities plumbed, refactoring it out into a SymbolServer plug-in makes lots of sense.

You can also read about the full DebugInfoD protocol (it's not very complicated) [from the RedHat blog introducing it in 2019](https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server#).

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


More information about the llvm-commits mailing list