LLVM core library supports demangling other mangled symbols other than itanium, such as D and Rust. LLD should use those demanglers in order to output pretty demangled symbols on error messages.
Details
- Reviewers
MaskRay - Group Reviewers
Restricted Project - Commits
- rG10e40a4ea350: [lld] Add support for other demanglers other than Itanium
rGe60d6dfd5acd: [lld] Add support for other demanglers other than Itanium
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/Common/Strings.cpp | ||
---|---|---|
27 | What do you mean by this? Is this validation or asking to be kept as is? There are checks against this already on llvm::demangle. See https://github.com/llvm/llvm-project/blob/main/llvm/lib/Demangle/Demangle.cpp#L51 . This includes checks not only for Itanium encoding but also for D and Rust. |
lld/ELF/Symbols.cpp | ||
---|---|---|
31 | Changed. |
lld/Common/Strings.cpp | ||
---|---|---|
27 | No action needed. See SymbolTable::getDemangledSyms. When extern "C++" is used for ld.lld --dynamic-list, every symbol is demangled. A large executable may have millions of symbols (chrome), so the performance matters. 1559632 of 1571293 symbols in chrome's symbol table starts with _, so the check may be redundant. | |
lld/include/lld/Common/Strings.h | ||
21–33 | llvm-project/lld nearly doesn't use doxygen \param \returns. The original comment style is sufficiently clear. The new \param just adds information a user can easily infer. |
I reverted this to not congestionante other builds and described the reason on the revert commit. I will do a clean build with all targets and try to reproduce this. I only tested this on x86 and WebAssembly targets since I haven't seen target specific code here. Additionally, I've tested this on an x86_64 environment.
The failure before the revert was:
tools/lld/MachO/CMakeFiles/lldMachO.dir/Symbols.cpp.o: In function `lld::demangle(llvm::StringRef, bool)':
This affects common code and all ports may be affected. You can use ninja check-lld to test all ports. not just check-lld-wasm or check-lld-elf
I've done it but only with "X86" on LLVM_TARGETS_TO_BUILD, since this can reduce build times. I've done a clean build with all targets and additionally the WebAssembly experimental target and the testsuite ran successfully with ninja check-lld. That said, I can't reproduce the issue in my environment. I can investigate further, but I don't have a PowerPC64 environment.
I finally reproduced this locally. The buildbot is configured with BUILD_SHARED_LIBS and my builds are built without it and use LLVM_LINK_LLVM_DYLIB and CLANG_LINK_CLANG_DYLIB respectively. Since I made lld::demangle symbol inline, Demangle LLVM component was missing on MachO. I added that component to the link list on CMakeLists.txt.
If you don't contribute to llvm-project, LLVM_TARGETS_TO_BUILD=host or just X86 is fine. For contribution, it's a good idea to enable all targets, otherwise some tests may be skipped.
(The missing Demangle dependency issue)
A -DBUILD_SHARED_LIBS=on build uses -Wl,-z,defs to link shared objects. It has some dependency checking effects: https://maskray.me/blog/2021-06-13-dependency-related-linker-options#z-defs
Personally I use -DBUILD_SHARED_LIBS=on for Debug build and -DBUILD_SHARED_LIBS=off for Release build, and ensure I built both modes if I touch CMake files.
Yeah, I'm going to start doing that.
(The missing Demangle dependency issue)
A -DBUILD_SHARED_LIBS=on build uses -Wl,-z,defs to link shared objects. It has some dependency checking effects: https://maskray.me/blog/2021-06-13-dependency-related-linker-options#z-defsPersonally I use -DBUILD_SHARED_LIBS=on for Debug build and -DBUILD_SHARED_LIBS=off for Release build, and ensure I built both modes if I touch CMake files.
Thanks for all that information. I didn't know about that. I will start building with it :)
The tests are in case demangle(...) is slow on non-mangled symbols.
I have linked chrome with --dynamic-list specifying a extern "C" version node and don't see much difference, so this seems fine.