链接器映射文件有时会出现损坏的符号,但并非总是如此

Question

作为构建过程的一部分,我们在编译可执行文件时生成一个映射文件.例如:

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

为了尝试从GCC 4.3/4.4迁移到GCC 4.9,我们设置了一个新的构建服务器.4.9构建服务器生成的映射文件没有损坏的符号名称.4.3/4.4构建服务器生成的映射文件.例如,运行上面的4.3我在地图文件中剪切了这个:

 .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

针对4.9运行相同的代码我得到以下代码段:

 .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

这是预期的变化吗？有没有办法用gcc 4.9(某种向后兼容性选项)生成错位输出？我问,因为我们构建中的后续工具使用符号文件并且在解码的名称上窒息.

Answer 1

有没有办法用 gcc 4.9 生成损坏的输出

映射文件的生成与 GCC 的版本无关，而与您正在使用的链接器版本有关（新旧构建服务器之间必须不同）。

来自男人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.

我猜测旧的链接器--demangle在生成输出映射时没有注意，而新的链接器已经修复了这个问题。