[PATCH] D69592: [ELF] Suggest the extern "C" name as an alternative spelling

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 30 16:04:48 PDT 2019


MaskRay marked 3 inline comments as done.
MaskRay added a comment.

> Doing this in both directions (when referencing a C definition with a C++ mangled name, or a C++ definition with an unmangled/C name) seems important/valuable. One comes from using a C header from C++ without wrapping it in "extern "C"" (hopefully inside the header, so it can be used reliably) and the other way happens when you want to write your C API's implementation in C++ (for C interop from a C++ library) but you haven't put "extern"C"" in the declaration of those functions in the header to be used from both C and C++.

I am open to both directions but was just waiting for more feedback for the other direction. Thanks for providing the motivation!



================
Comment at: lld/ELF/Relocations.cpp:764
+  // suggesting the part before (.
+  std::string demangled = toString(sym);
+  auto paren = demangled.find('(');
----------------
dblaikie wrote:
> grimar wrote:
> > I wonder if we might want to check `if (name.startswith("_Z"))` first. It might save a bit of calculations and isolate the logic a bit.
> Rather than demangling and stringifying the whole name, then using a heuristic to find the function name - might it be better to use LLVM's demangling APIs to retrieve the name directly? llvm::itanium_demangle::Node::getBaseName 
Thanks for the suggestion. I'll just call `ItaniumPartialDemangler::getFunctionName`. We can check whether the node kind is `KNodeType` but such optimization may not be necessary.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69592/new/

https://reviews.llvm.org/D69592





More information about the llvm-commits mailing list