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二元确定性？

THOUGHTS

不知何故，正在编译的代码实际上正在修改.debug_info的{{1}}部分。这个.obj使用了一堆boost库;这可能是原因吗？

更新

我查看了生成的程序集文件，它们是不同的。有意义的是，生成的.cpp会有所不同仍然没有理由为什么会发生这种情况。

更新上面的.obj命令不是执行的实际编译器命令：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文件是1.05mil的行，并且差异开始在〜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”
  ...

它持续了几百个字节。

现在，我仔细研究了我的比较，所有差异部分都归于.s。这个boost函数每次都生成不同的代码吗？

解决

原来这是一个boost::detail::variant::make_initializer_node错误。我将gcc编译为.cpp的所有排列，而对于Y＆gt; = 2，汇编文件-O<X> -ggdb<Y>和对象.s是不确定的。

我发现a gcc bug描述了这个问题。

我不得不删除其他帖子。。。的原因。

Answer 1

非决定论的原因

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

一种可能性是为二进制文件生成的调试信息以非确定性方式写入。例如，当编译器进程中调试信息的内存中布局不确定时，就会发生这种情况。我不了解海湾合作委员会的内部情况。但我猜这样的事情可能发生在

在调试信息输出中使用random GUIDs，
使用mangling of symbols in anonymous namespaces或
序列化一个hashmap，其中键是一个指向内存的指针，依次。

后一种非确定性来源通常被认为是编译器中的一个错误（例如GCC PR65015）

缓解

要强制__DATE__，__TIME__和__TIMESTAMP__宏的可重现扩展，必须模拟并伪造系统时间（例如，使用libfaketime/faketime）到编译器。 GCC的-Wdate-time命令行选项可用于在使用这些预定义宏时发出警告。

强制重现＆＃34;随机性＆＃34;对于GUID和mangling，您可以尝试使用-frandom-seed=<somestring>进行编译，其中<somestring>是您构建的唯一字符串（例如，您要编译的源文件内容的哈希应该这样做）

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

GCC .obj文件输出不确定（.debug_info，PROGBITS部分）

1 个答案:

非决定论的原因

缓解

另见