The linker map file sometimes has garbled characters, but not always

Question

As part of our build process, we generate a map file when compiling our executable file. For instance:

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 installed a new build server. The map file created by the assembly server 4.9 does not have malformed symbol names. The map file created by the build servers 4.3 / 4.4 does this. For example, doing the above with 4.3, I get this 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 garbled output using gcc 4.9 (some kind of backward compatibility option)? I ask, because the later tools in our assembly use a symbol file and choke on untied names.

Answer 1

Is there a way to generate garbled output using gcc 4.9

Generating a map file has nothing to do with the GCC version and everything related to the version of the linker used (which should 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 assume that the senior linker did not pay attention to --demangle when creating the output map, and the new linker fixed this.