================
@@ -771,6 +774,81 @@ class LoadAddressResolver {
lldb::addr_t m_best_internal_load_address = LLDB_INVALID_ADDRESS;
};
+/// Find a module by LLDB-specific unique identifier.
+///
+/// \param[in] uid The UID of the module assigned to it on construction.
+///
+/// \returns ModuleSP of module with \c uid. Returns nullptr if no such
+/// module could be found.
+static lldb::ModuleSP FindDebugModule(lldb::user_id_t uid,
+ const ModuleList &modules) {
+ lldb::ModuleSP module_sp;
+ modules.ForEach([&](const lldb::ModuleSP &m) {
+ if (m->GetID() == uid) {
+ module_sp = m;
+ return IterationAction::Stop;
+ }
+
+ auto *sym = m->GetSymbolFile();
+ if (!sym)
+ return IterationAction::Continue;
+
+ auto debug_modules = sym->GetDebugInfoModules();
----------------
Michael137 wrote:
@labath chose to locate the `.o` files using this.
I tried encoding the main module ID in the label. But that meant we'd have to
implement `ResolveFunctionCallLabel` on `SymbolFileDWARFDebugMap`. And the
error handling became quite awkward. Because we wouldn't know why we failed to
resolve the label in each particular `.o`. An alternative could've been to
encode the main module and optionally the ID of the module within the
debug-map. (something like `$__lldb_func:0x123-0x456`).
Wdyt?
https://github.com/llvm/llvm-project/pull/148877
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
