================
@@ -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);
----------------
labath wrote:
I don't think we want to put clang-specific types into the generic
FunctionCallLabel structure. If you want that, then the struct itself should by
plugin-specific. I think that'd would be doable if you make the generic code
treat the label.. generically (as a string I guess). The parsing would then
happen inside the SymbolFile, which can know the encoding scheme used, the
language and what not. In this world, it may make sense for this code to live
in the type system, but then I'd make sure it's called from the SymbolFile
class, and not directly from generic code.
However, I think that keeping the struct generic is also a viable option. We
just need to avoid language and plugin-specific terms. For the structor type
field, we could just say we have an additional "discriminator" field which the
plugin can use to discriminate different "variants" of the given function. In
this world, the label parsing should not be in a plugin. It could be just a
method defined in Expression.h, next to the struct definition.
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
