5

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

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（某种向后兼容选项）生成损坏的输出？我问是因为我们构建中的后续工具使用符号文件并且对解构名称感到窒息。

4

1 回答 1

2

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

映射文件的生成与 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我猜旧的链接器在生成输出映射时没有注意，而新的链接器已经解决了这个问题。

于 2015-12-24T05:43:38.263 回答