================
@@ -771,6 +774,63 @@ class LoadAddressResolver {
lldb::addr_t m_best_internal_load_address = LLDB_INVALID_ADDRESS;
};
+/// Returns address of the function referred to by the special function call
+/// label \c label.
+///
+/// \param[in] label Function call label encoding the unique location of the
+/// function to look up.
+/// Assumes that the \c FunctionCallLabelPrefix has been
+/// stripped from the front of the label.
+static llvm::Expected<lldb::addr_t>
+ResolveFunctionCallLabel(llvm::StringRef name,
+ const lldb_private::SymbolContext &sc,
+ bool &symbol_was_missing_weak) {
+ symbol_was_missing_weak = false;
+
+ if (!sc.target_sp)
+ return llvm::createStringError("target not available.");
+
+ auto ts_or_err = sc.target_sp->GetScratchTypeSystemForLanguage(
+ lldb::eLanguageTypeC_plus_plus);
----------------
Michael137 wrote:
The reason I made it `TypeSystemClang` specific is that in the follow-up patch
to support constructor/destructor variants
(https://github.com/llvm/llvm-project/pull/149827) I plan to put a Clang type
into the `FunctionCallLabel` structure. Of course I could avoid pulling Clang
in by using plain integers instead of
(`clang::CXXCtorType`/`clang::CXXDtorType`). Not sure if we get here outside of
expression evaluation, but happy to hoist this to somewhere more global.
Do you prefer me move this out of `TypeSystem` and into `Expression` (or
something similar). And we can refactor it if needed for the
constructor/destructor patch?
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
