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

[via llvm-commits]

================
@@ -4892,6 +4894,21 @@ void TargetProperties::SetDebugUtilityExpression(bool debug) {
   SetPropertyAtIndex(idx, debug);
 }
 
+Args TargetProperties::GetDebugInfoDURLs() const {
+  Args urls;
+  m_collection_sp->GetPropertyAtIndexAsArgs(ePropertyDebugInfoDURLs, urls);
+  return urls;
+}
+
+void TargetProperties::DebugInfoDURLsChangedCallback() {
+  Args urls = GetDebugInfoDURLs();
+  llvm::SmallVector<llvm::StringRef> dbginfod_urls;
+  std::transform(urls.begin(), urls.end(), dbginfod_urls.end(),
+                 [](const auto &obj) { return obj.ref(); });
+  llvm::setDefaultDebuginfodUrls(dbginfod_urls);
----------------
jimingham wrote:

This one is actually in kind of an awkward place in lldb.  

OTOH, if you have two different targets in lldb, they could be "one target remote debugging an Linux binary" and "one target debugging a local macOS binary".  So you would expect to be able to have different debuginfod sources for those very different binaries.  

However, because debug info & symbol parsing is slow, and a very common usage pattern for debug sessions is to  run the target multiple times where the main binary changes but everything else stays the same, lldb gets a good performance boost in this scenario by caching any "Modules" it has seen in a "global module cache".  

Also, when used in an IDE, you end up wanting one Debugger per target, not one Debugger and many targets, because the Debugger holds the command interpreter and you want each "debug session" to have a different console.  But in this case it's very common for all the Debugger sessions to be local to this machine, or to the same device, so to get the full benefits of the shared module cache it's held outside of the Debuggers.  So if a symbol-ingestion controlling setting was on the Target level, you could have two targets sharing the same Module, and if they have different debugInfod sources then it's a race to see which one gets queried, which is not so great.

So ideally you would like this to live in the Target because that's the level at which the decision of which source to choose is naturally made.  But because of this architectural oddity, that's a little hard to do internally.  Putting it as a global thing on Target will make something that's shared by all targets, but it gives a false impression that this will be target specific, when it currently can't be.

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