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