================
@@ -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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
