name-mangling

I wanted to give perf a shot to profile some programs after I saw this talk from CppCon 2015. I downloaded the same Google benchmark library that the guy uses in the talk, compiled my program with the appropriate switches, linked it to it, then used perf to record a run. The report option gives me this: As you can see the function names are not very readable. I assume this has to do with C++ name mangling. Interestingly, all the function names show up correctly in the video for the guy who gave the talk, but not for me. I don't think it's a case of completely missing the symbol information

After compilation with g++-4.9.3 -std=c++11 the code #include <iostream> #include <typeinfo> using namespace std; int main() { cout << typeid([]{}).name() << endl; } outputs Z4mainEUlvE_ as the mangled name of the given lambda on Linux x86_64. However, the c++filt tool is unable to unmangle it. It just outputs the input given to it, Z4mainEUlvE_ . How do I unmangle it? You can use GCC's special abi::__cxa_demangle function: #include <memory> #include <cstdlib> #include <cxxabi.h> #include <iostream> // delete malloc'd memory struct malloc_deleter { void operator()(void* p) const { std::free(p)

I found a number of similar questions (e.g. this , that or this ), but none of them helped me solve my problem. I have a *.so file (from the core of gnss-sdr ) that, as indicated by: $nm libgnss_system_parameters_dyn.so | c++filt |grep Gps_Eph contains the symbol Gps_Ephemeris::Gps_Ephemeris() , which is supposed to be a constructor. I've written some minimal code: #include <iostream> #include <core/system_parameters/gps_ephemeris.h> int main(int argc,const char* argv[]) { Gps_Ephemeris ge; return 0; } which I compile with: g++ main.cpp -std=c++0x -I some_include_path -L some_lib_path -l gnss

I have previously , here , been shown that C++ functions aren't easily represented in assembly. Now I am interested in reading 1 way or another because callgrind, part of valgrind, show them demangled while in assembly they are shown mangled, so i would like to either mangle the valgrind function output or demangle the assembly names of functions. Anyone ever tried something like that? I was looking at a website and found out the following: Code to implement demangling is part of the GNU Binutils package; see libiberty/cplus-dem.c and include/demangle.h. anyone ever tried something like that,

This question already has an answer here: GNU GCC (g++): Why does it generate multiple dtors? 2 answers And objdump of my .o file reveals that I have two different destructors for the same class. Why? Disassembly of section .text._ZN1AD0Ev: 0000000000000000 <_ZN1AD0Ev>: 0: 53 push %rbx 1: be 00 00 00 00 mov $0x0,%esi 6: 48 89 fb mov %rdi,%rbx 9: 48 c7 07 00 00 00 00 movq $0x0,(%rdi) 10: ba 2c 00 00 00 mov $0x2c,%edx 15: bf 00 00 00 00 mov $0x0,%edi 1a: e8 00 00 00 00 callq 1f <_ZN1AD0Ev+0x1f> 1f: 48 89 df mov %rbx,%rdi 22: be 08 00 00 00 mov $0x8,%esi 27: 5b pop %rbx 28: e9 00 00 00 00 jmpq 2d

I'm just wondering why name mangling was never standardized by the C++ standard. Clearly having different name mangling algorithms hurts interoperability[1] and I don't see any advantage of having it implementation-defined. That is, contrary to say calling conventions or size of primitives the machine itself doesn't care or even know how the function is called. So why wasn't it standardized and why is it still not standardized? Compilers have changed the rules in the past anyhow between versions. [1] all those people exporting functions as extern "C" speak volumes. The standard does not

I have a DLL that is written in C++ and I want to suppress the name mangling for a few exported methods. The methods are global and are not members of any class. Is there a way to achieve this? BTW: I'm using VS2008. paercebal "bradtgmurray" is right, but for Visual C++ compilers, you need to explicitly export your function anyway. But using a .DEF file as proposed by "Serge - appTranslator" is the wrong way to do it. What is the universal way to export symbols on Visual C++ ? Using the declspec(dllexport/dllimport) instruction, which works for both C and C++ code, decorated or not (whereas,