================
@@ -2471,6 +2471,47 @@ bool SymbolFileDWARF::ResolveFunction(const DWARFDIE
&orig_die,
return false;
}
+llvm::Error
+SymbolFileDWARF::FindAndResolveFunction(SymbolContextList &sc_list,
+ llvm::StringRef lookup_name) {
+ std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
+
+ DWARFDIE die;
+ Module::LookupInfo info(ConstString(lookup_name),
lldb::eFunctionNameTypeFull,
----------------
labath wrote:
> Hmm how do we do this without a name lookup?
> `SymbolFileDWARF::FindDefinitionDIE`?
Maybe, although I suspect that function only works on types/classes right now.
Ultimately, we are going to need some kind of a name lookup to go from the
declaration to the definition DIE, and I think that using the mangled name
(when it exists) for that is the fastest and simplest way to achieve that.
However, I think we should do that only if its needed. The most unique
identifier is the DIE ID, so I'd start by looking that up. After that, there
are three cases:
1. This is a definition DIE. We don't need to do anything. The DIE doesn't even
have to contain a mangled name. We just take the DW_AT_low/entry_pc, and we're
done.
2. This is a declaration of a CU-local entity (anonymous namespace). Here, we
need to do a lookup, but we know the result must be in the current CU. The
mangled name is the simplest way to do that. We could try to do structural
matching (like we do for classes with simplified template names) if
DW_AT_linkage_name is not present, but that's a job for another patch.
3. This is a declaration of a CU-local entity. We also need to do a lookup, but
the result could be anywhere(*) -- though we still may want to prefer the
definition in the current CU, if it exists.
(*) I just realized that "anywhere" also means "in a different module", which
means that there should be some sort of a fallback to searching in other
modules. Encoding the mangled name into the asm label might make that easier,
as a retry could happen at a different level -- though it would still be nice
if the "owning module" would signal that this kind of search is necessary
(instead of blindly doing the full search whenever the first module doesn't
produce a match).
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
