[Lldb-commits] [lldb] [lldb][Expression] Encode Module and DIE UIDs into function AsmLabels (PR #148877)

[Michael Buch via lldb-commits]

================
@@ -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