Failed to demangle some symbols

[zchrissirhcz]

Failed to demangle some symbols, such as ??$emplace_back@AEBM@?$vector@MV?$allocator@M@std@@@std@@QEAA?A_TAEBM@Z.

Tried with latest LLVM commit but not working.

Reported in llvm/llvm-project#63342 now.

[nico]

From the upstream issue, the correct demangling is

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"

apparently.

[nico]

How did you end up with these symbols? Is that from building a binary with cl.exe, or with clang-cl.exe? I'm wondering if clang-cl also mangles it incorrectly, in addition to not demangling it right.

Do you happen to have a reduced source file that produces these symbols?

[nico]

For this https://godbolt.org/z/6env1z5Tn , cl.exe seems to produce ??$emplace_back@H@?$vector@HV?$allocator@H@@@@QEAAAEAH$QEAH@Z while clang-cl produces ??$emplace_back@H@?$vector@HV?$allocator@H@@@@QEAAAEAH$$QEAH@Z (note $ vs $$; the rest is identical).

Edit: This is incorrect; godbolt just shows it incorrectly in the call instruction. The two $$ are there in the fn def as long as demangling is disabled in the view options. Ignore this comment.

[zchrissirhcz]

cl.exe was used to generate the reported symbols. I didn't try clang-cl.exe yet.

Symbols are generated from actual project code, currently just have no network access from work machine, let me try reduce source files once available.

[zchrissirhcz]

My original purpose is to detect conflict symbols, i.e. same name symbols, but in different .obj files, which makes the linker links to the wrong symbols, then my program just "crash".

[zchrissirhcz]

Hi, @nico I upload one simple reproduce project a.zip.

#pragma once

#include <vector>

struct Point
{
    float x;
    float y;
    Point() {
        x = 0;
        y = 0;
    }
    Point(int _x, int _y): x(_x), y(_y){}
};

float random_sum(int n);

#include "point.h"

#include <stdlib.h>

float random_sum(int n)
{
    std::vector<Point> res;
    for (int i = 0; i < n; i++)
    {
        float x = rand()/RAND_MAX;
        float y = rand()/RAND_MAX;
        res.emplace_back(Point(x, y));
    }

    float sum = 0;
    for (int i = 0; i < n; i++)
    {
        sum += res[i].x + res[i].y;
    }
    return sum / n;
}

And the symbol ??$emplace_back@UPoint@@@?$vector@UPoint@@V?$allocator@UPoint@@@std@@@std@@QEAA?A_T$$QEAUPoint@@@Z cannot be tranformed to its code via demumble.

[danfe]

Some symbols from libdatachannel built with GCC 9.3.0 for ARMv7 also won't demumble:

_ZNSt17_Optional_payloadIN3rtc22CertificateFingerprintELb1ELb0ELb0EECI2St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc22CertificateFingerprintELb0ELb0ELb0EECI2St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc11DescriptionELb0ELb0ELb0EECI1St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc11ProxyServerELb1ELb0ELb0EECI2St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc11DescriptionELb1ELb0ELb0EECI2St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc11ProxyServerELb0ELb0ELb0EECI2St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc11DescriptionELb1ELb0ELb0EECI1St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc11ProxyServerELb1ELb0ELb0EECI1St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc11DescriptionELb0ELb0ELb0EECI2St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc22CertificateFingerprintELb0ELb0ELb0EECI1St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc11ProxyServerELb0ELb0ELb0EECI1St22_Optional_payload_baseIS1_EEbRKS4_
_ZNSt17_Optional_payloadIN3rtc22CertificateFingerprintELb1ELb0ELb0EECI1St22_Optional_payload_baseIS1_EEbRKS4_