[MsDemangle] Read entire chain of target names in special tables#155630
Merged
Conversation
Contributor
Author
|
Ping |
zmodem
reviewed
Nov 5, 2025
zmodem
left a comment
Contributor
There was a problem hiding this comment.
Sorry, I must have missed this before. Thanks for fixing this.
| if (!consumeFront(MangledName, '@')) | ||
| STSN->TargetName = demangleFullyQualifiedTypeName(MangledName); | ||
|
|
||
| NodeList *TargetCurrent = nullptr; |
Contributor
There was a problem hiding this comment.
Instead of building a linked list here, could we just put these into a SmallVector and create the NodeArray from that directly?
zmodem
reviewed
Nov 5, 2025
zmodem
left a comment
Contributor
There was a problem hiding this comment.
Thanks! I think that's much easier to read.
dtcxzyw
reviewed
Nov 5, 2025
| #include "llvm/Demangle/MicrosoftDemangle.h" | ||
|
|
||
| #include "llvm/ADT/ArrayRef.h" | ||
| #include "llvm/ADT/SmallVector.h" |
Member
There was a problem hiding this comment.
I cannot build LLVM with gcc+gnu ld after this patch. It introduces cyclic dependencies (LLVMSupport <-> LLVMDemangle).
FAILED: lib/libLLVMDemangle.so.22.0git
: && /usr/bin/c++ -fPIC -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-dangling-reference -Wno-redundant-move -Wno-pessimizing-move -Wno-array-bounds -Wno-stringop-overread -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -Wl,-z,defs -Wl,-z,nodelete -Wl,-rpath-link,/data/zyw/dev/llvm-build/./lib -Wl,--gc-sections -shared -Wl,-soname,libLLVMDemangle.so.22.0git -o lib/libLLVMDemangle.so.22.0git lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o lib/Demangle/CMakeFiles/LLVMDemangle.dir/ItaniumDemangle.cpp.o lib/Demangle/CMakeFiles/LLVMDemangle.dir/MicrosoftDemangle.cpp.o lib/Demangle/CMakeFiles/LLVMDemangle.dir/MicrosoftDemangleNodes.cpp.o lib/Demangle/CMakeFiles/LLVMDemangle.dir/RustDemangle.cpp.o lib/Demangle/CMakeFiles/LLVMDemangle.dir/DLangDemangle.cpp.o -Wl,-rpath,"\$ORIGIN/../lib:" && :
/usr/bin/ld: lib/Demangle/CMakeFiles/LLVMDemangle.dir/MicrosoftDemangle.cpp.o: in function `llvm::SmallVectorTemplateCommon<llvm::ms_demangle::Node*, void>::grow_pod(unsigned long, unsigned long)':
/data/zyw/dev/llvm-project/llvm/include/llvm/ADT/SmallVector.h:140:(.text._ZN4llvm11ms_demangle9Demangler30demangleSpecialTableSymbolNodeERSt17basic_string_viewIcSt11char_traitsIcEENS0_20SpecialIntrinsicKindE+0x28c): undefined reference to `llvm::SmallVectorBase<unsigned int>::grow_pod(void*, unsigned long, unsigned long)'
collect2: error: ld returned 1 exit status
Contributor
|
I believe this one broke a few of our buildbots, e.g., https://lab.llvm.org/buildbot/#/builders/203/builds/28219 From the log |
Nerixyz
added a commit
that referenced
this pull request
Nov 5, 2025
Using `SmallVector` would introduce a dependency cycle (see #155630 (comment)), so this uses a NodeList.
llvm-sync Bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Nov 5, 2025
…s (#166586) Using `SmallVector` would introduce a dependency cycle (see llvm/llvm-project#155630 (comment)), so this uses a NodeList.
markrvmurray
pushed a commit
to markrvmurray/llvm-mc6809
that referenced
this pull request
Jun 14, 2026
Using `SmallVector` would introduce a dependency cycle (see llvm/llvm-project#155630 (comment)), so this uses a NodeList.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When there's a deep inheritance hierarchy of multiple C++ classes (see below), then the mangled name of a VFTable can include multiple key nodes in the target name.
For example, in the following code, MSVC will generate mangled names for the VFTables that have up to three key classes in the context.
Code
This will include
??_7C@@6BInd1@@Ind4@@Ind5@@@(and every other combination). Microsoft's undname will demangle this to "const C::`vftable'{for `Ind1's `Ind4's `Ind5'}". Previously, LLVM would demangle this to "const C::`vftable'{for `Ind1'}".With this PR, the output of LLVM's undname will be identical to Microsoft's version. This changes
SpecialTableSymbolNode::TargetNameto a node array which contains each key from the name. Unlike namespaces, these keys are not in reverse order - they are in the same order as in the mangled name.