================
@@ -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:
I see. So, we definitely don't want to look for the definition DIE just so we
can encode it into the label. What we *could* do is encode the declaration DIE,
and then when (and *if* -- I expect that the majority of functions will never
be called) we need to resolve the call, we look up the matching definition DIE.
That would be my ideal implementation as that's the only way to avoid
ambiguities arising from multiple functions having identical linkage names
(these occur in anonymous namespace. the ambiguities are solved because there's
no need to look up definition DIEs, as these DIEs will be CU-local and always
be definitions). It would also let us debug code which doesn't include the
linkage names in the definition DIEs (which is what clang does with `-gsce`).
Another reason for dropping the linkage names might be to reduce the memory
footprint of long asm labels, but if this isn't big, we may want to keep them
anyway to help with debugging.
That said, I can imagine postponing that to a later time. However, I'd suggest
designing this API such that it is possible to implement that in the future,
such as by passing the entire FunctionCallLabel object so that the module can
choose what it uses to perform the lookup.
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
