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

[Daniel Thornburgh via lldb-commits]

================
@@ -396,8 +398,22 @@ Symbols::LocateExecutableSymbolFile(const ModuleSpec &module_spec,
       }
     }
   }
-
-  return LocateExecutableSymbolFileDsym(module_spec);
+  FileSpec dsym_bundle = LocateExecutableSymbolFileDsym(module_spec);
+  if (dsym_bundle)
+    return dsym_bundle;
+
+  // If we didn't find anything by looking locally, let's try Debuginfod.
+  if (module_uuid.IsValid() && llvm::canUseDebuginfod()) {
+    llvm::object::BuildID build_id(module_uuid.GetBytes());
+    llvm::Expected<std::string> result =
+        llvm::getCachedOrDownloadDebuginfo(build_id);
+    if (result)
+      return FileSpec(*result);
+    // An error is just fine, here...
+    consumeError(result.takeError());
----------------
mysterymath wrote:

Looks like gdb has a `set debuginfod verbose on/off` setting for this. There's also the generic `DEBUGINFOD_VERBOSE` environment variable. If set, this triggers remote logging to stderr.

The environment variable is something we generally want to support for debuginfod lookups; that could probably safely live in the debuginfod client library itself, as it does with libdebuginfod. If LLDB had its own setting for this, it may be able to invoke a setter in the client library, but current everything in the client library is global, so there may be some threading gotchas there.

For reference, here's the gdb settings for debuginfod: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Debuginfod-Settings.html
And the environment variables:
https://manpages.debian.org/testing/debuginfod/debuginfod.8.en.html#ENVIRONMENT_VARIABLES


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