c++ - GCC .obj 文件输出不确定(.debug_info，PROGBITS 部分)

Question

我的编译命令是
C:\work\PROJ-test\QNX_SDK\host\win32\x86/usr/bin/qcc -c -Wc,-frandom-seed="sadfsasafssadsa" -Wc,-MP,-MT,C:/work/PROJ-test/N_Manag/src/bld/N_Manag//armle-v7/release/nav_event_rcv.cpp.o,-MMD,C:/work/PROJ-test/N_Manag/src/bld/N_Manag//armle-v7/release/nav_event_rcv.cpp.d -Vgcc_ntoarmv7le -w9 -shared -O3 -ggdb3 -DBUILD_VERSION= -DPASLOGOPTIONS=0x02 -DPASLOGAPPZONES=31,23,30,9,8,3 -DNS1_5PORT -DBOARD_TYPE=PRODUCTION C:/work/PROJ-test/N_Manag/src/nav_event_rcv.cpp -o C:/work/PROJ-test/N_Manag/src/bld/N_Manag//armle-v7/release/nav_event_rcv.cpp.o

当我连续两次运行此命令时，两个 .obj文件不同，而不仅仅是时间戳的几个字节。

我们正在切换构建系统，因此我们希望我们的构建是二进制兼容的。我的绝大多数目标文件都是二进制相同的。一些使用 __DATE__ 的和 __TIME__宏在几个字节上有所不同，但这个宏非常不同!

我使用了一个 elf-dump 实用程序，发现两次编译之间截然不同的部分是这个

  [544] .debug_info
       PROGBITS        00000000 047d70 1021ed 00   0   0  1
       [00000000]: 

但我不知道是什么PROGBITS包含以及为什么它包含用于连续编译的不同项目。 This site只是说 PROGBITS是一个属性，但不是它表示的内容(以及为什么它在连续编译时会有所不同)。

问题

如何生成 .obj二进制确定性？

想法

不知何故，正在编译的代码实际上是在修改 .debug_info节.obj .这.cpp使用一堆 boost 库；这可能是原因吗？

更新

我查看了正在生成的程序集文件，它们是不同的。结果 .obj 是有道理的s 会有所不同。
仍然不明白为什么会这样。

更新qcc上面的命令不是实际执行的编译器命令:qcc是一个编译器“重定向器”，因为它将调用与 -V 匹配的那个争论。“真正的”编译器调用是这样的:

C:/work/Proj/QNX_SDK/host/win32/x86/usr/lib/gcc/arm-unknown-nto-qnx6.5.0eabi/4.4.2/cc1plus -Wall -O3 -ggdb3 -DBUILD_VERSION= -DPASLOGOPTIONS=0x02 -DPASLOGAPPZONES=31,23,30,9,8,3 -DNS1_5PORT -DBOARD_TYPE=PRODUCTION -quiet -fno-builtin -fpic -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mlittle-endian -nostdinc -nostdinc++ -D__cplusplus -D__QNX__ -D__QNXNTO__ -D__GNUC__=4 -D__GNUC_MINOR__=4 -D__GNUC_PATCHLEVEL__=2 -D__NO_INLINE__ -D__DEPRECATED -D__EXCEPTIONS -D__unix__ -D__unix -D__ELF__ -fpic -DPIC=1 -D__ARM__ -D__arm__ -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -D__LITTLEENDIAN__ -D__ARMEL__ -U__ARMEB__ -frandom-seed=sadfsasafssadsa -MP -MT C:/work/Proj/N_Manag/src/bld/N_Manag//armle-v7/release/nav_event_rcv.cpp.o -MMD C:/work/Proj/N_Manag/src/bld/N_Manag//armle-v7/release/nav_event_rcv.cpp.d -isystem C:/work/Proj/QNX_SDK/target/qnx6/usr/include -isystem C:/work/Proj/QNX_SDK/host/win32/x86/usr/lib/gcc/arm-unknown-nto-qnx6.5.0eabi/4.4.2/include -isystem C:/work/Proj/QNX_SDK/target/qnx6/usr/include/cpp/c -isystem C:/work/Proj/QNX_SDK/target/qnx6/usr/include/cpp C:/work/Proj/N_Manag/src/nav_event_rcv.cpp -dumpbase C:/work/Proj/N_Manag/src/nav_event_rcv.cpp -o C:\work\Proj\nav_event_rcv.s

更新

我认为值得看看 .s汇编输出，因为那里存在重大差异。

请记住，我使用的是 -frandom-seed .

.s文件有 105 万行，差异开始于 ~900k 行。

左:

.LASF17345:
.ascii "_ZN5boost6detail7variant21make_initializer_node5app"
.ascii "lyINS_3mpl4pairINS3_INS5_INS3_INS5_INS3_INS5_INS3_I"
.ascii "NS5_INS3_INS5_INS3_INS5_INS3_INS5_INS3_INS5_INS3_IN"
.ascii "S5_INS3_INS5_INS3_INS5_INS3_INS5_INS3_INS5_INS3_INS"
.ascii "5_INS3_INS5_INS3_INS5_INS3_INS5_INS3_INS5_INS1_16in"
.ascii "itializer_rootEN4mpl_4int_ILi0EEEEENS4_6l_iterINS4_"
...

右:

.LASF17764:
.ascii "_ZNKSt8numpunctIcE13decimal_pointEv\000"
.LASF10304:
.ascii "cAlpha0\000"
.LASF10222:
.ascii "usWeek\000"
.LASF14117:
.ascii "_ZN5boost10shared_ptrI27TnRespTravelEstimationEvent"
.ascii "EaSERKS2_\000"
...

它持续了数百个字节。

现在我仔细检查了我的 beyond compare，所有不同的部分都归因于 boost::detail::variant::make_initializer_node .那个 boost 函数每次生成不同的代码吗？

决议

结果是 gcc漏洞。我编译了我的 .cpp与 -O<X> -ggdb<Y> 的所有排列对于 Y>=2，程序集文件 .s和对象 .obj是不确定的。

我找到了 a gcc bug描述了这个问题。

---

我不得不删除另一个帖子。 . .原因。

Answer 1

非确定性的原因

通常的罪魁祸首是宏 __DATE__ , __TIME__ , __TIMESTAMP__编译器将其扩展为根据系统时间计算的值。

一种可能性是为二进制文件生成的调试信息是以非确定性方式编写的。例如，当编译器进程中调试信息的内存布局不确定时，就会发生这种情况。我不知道 GCC 的内部结构。但我想当

• 使用random GUIDs在调试信息输出中，
• 使用mangling of symbols in anonymous namespaces , 或
• 按顺序序列化一个散列图，其中键是指向内存的指针。

后者的不确定性来源通常被认为是编译器中的错误(例如 GCC PR65015)

缓解

强制对 __DATE__ 进行可重复的扩展, __TIME__和 __TIMESTAMP__宏，必须向编译器模拟和伪造系统时间(例如，通过使用 libfaketime/faketime )。 -Wdate-time GCC 的命令行选项可用于在使用这些预定义宏时发出警告。

要强制 GUID 和重整的可重现“随机性”，您可以尝试使用 -frandom-seed=<somestring> 进行编译其中 <somestring>是您构建的唯一字符串(例如，您正在编译的源文件内容的哈希应该这样做)。

或者，您可以尝试在没有调试信息的情况下进行编译(例如，没有 -ggdb 等标志)或稍后使用一些剥离工具删除调试信息部分。

另见

• https://wiki.debian.org/ReproducibleBuilds/About
• How to produce deterministic binary output with g++? - Stack Overflow