Linker map file sometimes has mangled symbols but not always

Question

As part of our build process we generate a map file when we compile our executable. For example:

g++ -Wl,-Map,/tmp/foo.map -o foo foo.cpp

In an attempt to migrate from GCC 4.3/4.4 to GCC 4.9 we have setup a new build server. The map file generated by the 4.9 build server does not have mangled symbol names. The map file generated by the 4.3/4.4 build servers do. For example, running the above with 4.3 I get this snipped in the map file:

 .plt           0x0000000000400700       0x90 /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crt1.o
                0x0000000000400710                _ZNSolsEi@@GLIBCXX_3.4
                0x0000000000400720                _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4
                0x0000000000400730                __libc_start_main@@GLIBC_2.2.5

Running the same code against 4.9 I get the following snippet:

 .plt           0x00000000004006e0       0x80 /usr/lib/../lib64/crt1.o
                0x00000000004006f0                std::ostream::operator<<(int)@@GLIBCXX_3.4
                0x0000000000400700                std::ios_base::Init::Init()@@GLIBCXX_3.4
                0x0000000000400710                __libc_start_main@@GLIBC_2.2.5
                0x0000000000400720                __cxa_atexit@@GLIBC_2.2.5

Is this change expected? Is there a way to generate mangled output with gcc 4.9 (some kind of backwards compatibility option)? I ask because later tools in our build use the symbol file and are choking on the demangled names.

score 2 · Accepted Answer · answered Dec 24 '15 at 05:43

Is there a way to generate mangled output with gcc 4.9

The map file generation has nothing to do with the version of GCC, and everything to do with the version of linker you are using (which must be different between the old and the new build server).

From man ld:

 --demangle[=style]
 --no-demangle
       These options control whether to demangle symbol names in error
       messages and other output.  When the linker is told to demangle,
       it tries to present symbol names in a readable fashion: it strips
       leading underscores if they are used by the object file format,
       and converts C++ mangled symbol names into user readable names.
       Different compilers have different mangling styles.  The optional
       demangling style argument can be used to choose an appropriate
       demangling style for your compiler.  The linker will demangle by
       default unless the environment variable COLLECT_NO_DEMANGLE is
       set.  These options may be used to override the default.

I am guessing that the older linker did not pay attention to --demangle when generating the output map, and the newer linker has fixed that.

Linker map file sometimes has mangled symbols but not always

1 Answers1