[MicrosoftDemangle] Failed to demangle the following symbols

zchrissirhcz commented 1 year ago

Problem Description

I use latest llvm/lib/Demangle files to compile demumble, then use demumble.exe to undecorate symbols that generated from C++ files with MSVC. I think demumble just calls LLVM's API, and it failed to demumble the following symbols:

??$emplace_back@AEBM@?$vector@MV?$allocator@M@std@@@std@@QEAA?A_TAEBM@Z
??$_Emplace_back_with_unused_capacity@AEBM@?$vector@MV?$allocator@M@std@@@std@@AEAA?A_TAEBM@Z
??$emplace_back@N@?$vector@NV?$allocator@N@std@@@std@@QEAA?A_T$$QEAN@Z
??$_Emplace_back_with_unused_capacity@N@?$vector@NV?$allocator@N@std@@@std@@AEAA?A_T$$QEAN@Z
??$emplace_back@AEBN@?$vector@NV?$allocator@N@std@@@std@@QEAA?A_TAEBN@Z
??$_Emplace_back_with_unused_capacity@AEBN@?$vector@NV?$allocator@N@std@@@std@@AEAA?A_TAEBN@Z
??$_To_address@PEAN@std@@YA?A_PAEBQEAN@Z
??$_To_address@PEAM@std@@YA?A_PAEBQEAM@Z
??$_Get_unwrapped@AEBQEAM@std@@YA?A_TAEBQEAM@Z
??$_Get_unwrapped@AEBQEAN@std@@YA?A_TAEBQEAN@Z
_TI3?AVbad_array_new_length@std@@
_CTA3?AVbad_array_new_length@std@@
_CT??_R0?AVbad_array_new_length@std@@@8??0bad_array_new_length@std@@QEAA@AEBV01@@Z24
_CT??_R0?AVbad_alloc@std@@@8??0bad_alloc@std@@QEAA@AEBV01@@Z24
_CT??_R0?AVexception@std@@@8??0exception@std@@QEAA@AEBV01@@Z24
??$emplace_back@AEBH@?$vector@HV?$allocator@H@std@@@std@@QEAA?A_TAEBH@Z
??$_Emplace_back_with_unused_capacity@AEBH@?$vector@HV?$allocator@H@std@@@std@@AEAA?A_TAEBH@Z
??$_Get_unwrapped@AEBQEAH@std@@YA?A_TAEBQEAH@Z
??$_To_address@PEAH@std@@YA?A_PAEBQEAH@Z
_TI2?AVbad_cast@std@@
_CTA2?AVbad_cast@std@@
_CT??_R0?AVbad_cast@std@@@8??0bad_cast@std@@QEAA@AEBV01@@Z24
??$_Get_unwrapped@AEBQEAV?$vector@V?$vector@UMYRECT@@V?$allocator@UMYRECT@@@std@@@std@@V?$allocator@V?$vector@UMYRECT@@V?$allocator@UMYRECT@@@std@@@std@@@2@@std@@@std@@YA?A_TAEBQEAV?$vector@V?$vector@UMYRECT@@V?$allocator@UMYRECT@@@std@@@std@@V?$allocator@V?$vector@UMYRECT@@V?$allocator@UMYRECT@@@std@@@std@@@2@@0@@Z
??$_Get_unwrapped@AEBQEAV?$vector@UMYRECT@@V?$allocator@UMYRECT@@@std@@@std@@@std@@YA?A_TAEBQEAV?$vector@UMYRECT@@V?$allocator@UMYRECT@@@std@@@0@@Z
??$_Get_unwrapped@AEBQEAUMYRECT@@@std@@YA?A_TAEBQEAUMYRECT@@@Z
??$emplace_back@M@?$vector@MV?$allocator@M@std@@@std@@QEAA?A_T$$QEAM@Z
??$_Emplace_back_with_unused_capacity@M@?$vector@MV?$allocator@M@std@@@std@@AEAA?A_T$$QEAM@Z

Reproduce

OS: Windows (Windows 11)

LLVM Version:

commit 807adcf4b9cca5586fd1fb669811768528d9dd1d (HEAD -> main, origin/main, origin/HEAD)
Author: Philip Reames <preames@rivosinc.com>
Date:   Wed Jun 14 09:47:24 2023 -0700

[RISCV][InsertVSETVLI] Rework code structure to make reasoning about undefined lanes explicit [NFC]

We already have several places in this code which reason about whether the inactive lanes are defined, and are about to add one more in D151653. Let's go ahead and common the code so that we don't have the same concept repeating in multiply places.

Differential Revision: https://reviews.llvm.org/D152844

compile demumble:

git clone https://github.com/nico/demumble
cd demumble
git log

commit df938e45c2b0e064fb5323d88b692d03b451d271 (HEAD -> main, origin/main, origin/HEAD) Author: Nico Weber thakis@chromium.org Date: Tue Mar 22 16:08:26 2022 -0400

Update LLVM lib/Demangle 87039c048c0cb..3de6b1ce0dd1d735

cp /d/github/LLVM/llvm/include/llvm/Demangle/*.h third_party/llvm/include/llvm/Demangle/
cp /d/github/LLVM/llvm/include/llvm/Demangle/*.def third_party/llvm/include/llvm/Demangle/
cp /d/github/LLVM/llvm/lib/Demangle/*.cpp third_party/llvm/lib/Demangle/
cp /d/github/LLVM/llvm/LICENSE.TXT third_party/llvm/LICENSE.txt

Modify print_demangled() function in demumble.cc to the following:

static void print_demangled(const char* format, const char* s, size_t* n_used) {
  if (char* itanium = llvm::itaniumDemangle(s)) {
    printf(format, itanium, s);
    free(itanium);
  } else if (char* rust = llvm::rustDemangle(s)) {
    printf(format, rust, s);
    free(rust);
  } else if (char* ms = llvm::microsoftDemangle(s, n_used, NULL)) {
    printf(format, ms, s);
    free(ms);
  } else {
    printf("%s", s);
  }
}

Modify CMakeLists.txt last 2 lines to (use C++17 instead of C++14):

set_target_properties(demumble PROPERTIES CXX_STANDARD 17
                                          CXX_STANDARD_REQUIRED ON)

Build project:

cmake -S . -B build -G "Visual Studio 17 2022" -A x64
cmake --build build
.\build\Debug\demumble.exe ??$emplace_back@AEBM@?$vector@MV?$allocator@M@std@@@std@@QEAA?A_TAEBM@Z

zchrissirhcz commented 1 year ago

I also use the VS 2022 provided undname.exe, which gives expected result:

D:\github\demumble>.\build\Debug\demumble.exe ??$emplace_back@AEBM@?$vector@MV?$allocator@M@std@@@std@@QEAA?A_TAEBM@Z
??$emplace_back@AEBM@?$vector@MV?$allocator@M@std@@@std@@QEAA?A_TAEBM@Z

D:\github\demumble>"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\bin\Hostx64\x64\undname.exe" ??$emplace_back@AEBM@?$vector@MV?$allocator@M@std@@@std@@QEAA?A_TAEBM@Z
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- "??$emplace_back@AEBM@?$vector@MV?$allocator@M@std@@@std@@QEAA?A_TAEBM@Z"
is :- "public: decltype(auto) __cdecl std::vector<float,class std::allocator<float> >::emplace_back<float const & __ptr64>(float const & __ptr64) __ptr64"

llvmbot commented 1 year ago

@llvm/issue-subscribers-clang-codegen

nico commented 1 year ago

Probably easier to demonstrate the upstream bug using llvm-undname instead of demumble.

cpplearner commented 1 year ago

The problematic parts seem to be ?A_P and ?A_T (specifically, _P and _T), which correspond to auto and decltype(auto) respectively.

llvm / llvm-project