3

I am using a Yagarto toolchain on Windows to compile a codebase of about 100K lines of code.

We have two development PCs. However, they each build slightly different binaries despite having the same toolchain and building the same source code.

I have checked using MD5 that we have the same compiler binaries, the same system headers, and we are compiling the same source, with the same commandline being passed to GCC, yet there are subtle differences.

Out of the 81 object files in our codebase, 77 compile exactly the same; and four have minor differences. There is no functional difference, but since we are going to be supporting the compiled binaries, I would like to get to the bottom of this issue.

The "arm-elf-gcc.exe" is dated Jul 16 2006. The output of "arm-elf-gcc -v" is:

Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure --target=arm-elf --prefix=/home/yagarto/yagarto --disable-nls --disable-shared --disable-threads --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --enable-languages=c,c++ --enable-interwork --enable-multilib --with-newlib --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --enable-win32-registry=yagarto -v
Thread model: single
gcc version 4.1.1

Here is an example from the list files of the different generated code:

.LCB1356:
mov r7, #0
mov r5, #2
str r7, [sp, #16]
str r7, [sp, #20]
str r7, [sp, #24]
str r7, [sp, #28]
str r7, [sp, #40]
.L231:

.LCB1356:
mov r7, #0
mov r5, #2
str r7, [sp, #16]
str r7, [sp, #20]
str r7, [sp, #40]
str r7, [sp, #24]
str r7, [sp, #28]
.L231:

In the two cases, just the order of variables in the stack frame is different; all the code is the same except the variables were in a different order. ("diff" on the list files just shows up various other lines corresponding to #40 being swapped with #28 and so on).

This change is obviously harmless (although I would like to know why), but in two of the other object files, the size of the text segment is actually 4 bytes larger in one version, and as well as variables being in different order on the stack frame, there are a couple of instructions that differ.

One PC is a Intel Core 2 Duo running Windows 2000, and the other is a AMD X4 running Windows 7. Each PC reliably reproduces the same build, but one PC's build differs to the others.

Is it possible that GCC will optimize differently depending on what CPU is actually being used for the build? (not the target CPU). Or what else might cause this discrepancy?

M.M
  • 138,810
  • 21
  • 208
  • 365
  • 2
    Not directly related, but we've been seeing the same issue with a different toolchain (IAR for MSP430, FWIW). Our current theory is that the ordering is affected by the directory order of the files, which is the most likely difference between the machines. It could be creation order or timestamp order, depending on the toolchain. I'm looking forward to seeing if someone has a solid answer to this one. – Erik Johnson Jan 20 '14 at 08:21
  • Which files? Each unit's #included files must be processed in the order specified; and it doesn't make a difference which order you compile the units in (each unit always comes out the same on the same PC). – M.M Jan 20 '14 at 23:11
  • I wasn't the one who was looking into it, so I'm not up on the fine details. As I recall, his opinion in our toolchain was that the linker was processing modules in directory order, so it differed from system to system. If we ever get to a point where this is a priority again, I'm going to compare builds from clean checkouts on different systems vs. builds from the root from which the release was tagged. However, that won't be before spring in my case. – Erik Johnson Jan 21 '14 at 06:35
  • OK. Sounds like your case may be different to mine then, as mine is the compiler generating different code for each object file; the problem occurs before the linking stage. – M.M Jan 22 '14 at 22:03

0 Answers0