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生成错位输出

地图文件生成 nothing 与GCC版本有关，而所有与您正在使用的链接器版本有关（必须在旧的和新的构建服务器。）

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

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

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

1 个答案: