>> They pre-processor output from each run is the same. So it appears
for these two source files that the issue with the object code being
generated differing comes from the compiler. It is the object files
before linking that are different (as well as the resulting final
binaries but we have tracked it back to the object files emitted by the
compiler as the first point where the files differ.
You are missing a step. You are thinking "visual studio" type approach
which creates a .O file directly. GCC does it the traditional way - it
generates assembler output.
The next step is the *ASSEMBLER* output, the "-S" output, the
pre-processor output is from -E.
Is the "-S" output same or different?
If same - Then the problem is in GAS.... (the assembler)
If it is in GAS, you can use "objdump" for your target, ie:
mips32-<SOMETHING>-objdump, and dump the elf <dot><oh> file, and see
what is different.
Often, you find something dumb - like a date/time stamp of the input
file, you forgot about.
ie: I have been burned by this construct buried deep within layers of
macro expansion.
printf("This file was built on: %s at %s\n", __DATE__ , __TIME__ );
I had our "identical binary image" rule amended to read something like this:
Resulting binary must be identical after using the command line tool
FOOBAR that "back date/time stamps" the image header and re-calculates
the image checksum. We also wrote a tool, which did a 'binary image
compare' and knew about the location of our "image build date/time
stamp" and could ignore it.
-Duane.
