gcc C++ compiler - obj file creation non-deterministic?

Question

PROBLEM

For a certain .obj, my compiler "toggles" the value of a byte between builds even when I don't change anything. It's always the same byte position and it's always one of two values: 0x00 or 0x80

BACKGROUND

I'm using QNX C++ compiler; it's gcc-based so just think of it as gcc.

My make command is:

C:\make421.exe all --trace --debug=vjm --jobs=16 --output-sync=recurse --print-directory --print-data-base

The make rule for this object lists files which are ALL contained within my top-level working folder.

It only depends on one .cpp file which doesn't change - I'm doing Beyond Compare on the entire HMI_FORGF folder which is where the artifacts are - and I'm also diffing the other folders that hold libraries.

ABSOLUTELY NOTHING IS CHANGING!

QUESTION

Why is one byte being toggled with no change in . . . ANYTHING?

Yes I'll also ask QNX but wanted to see if anyone has experienced something like this.

UPDATE

I did a diff of the objdump -xSsDg output but it's over 100MB is size so can't upload it (if anyone knows a site to host this let me know).

There are two sections in the diff that are different:

First section, left

Contents of section .ARM.exidx.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE:
 0000 00000000 00000000                    ........

First section, right

Contents of section .ARM.exidx.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE:
 0000 00000000 00000080                    ........

Second section, left

00000000 <.ARM.exidx.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE>:
    ...
            0: R_ARM_PREL31 .text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE
            0: R_ARM_NONE   __aeabi_unwind_cpp_pr1
            4: R_ARM_PREL31 .ARM.extab.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE

Second section, right:

00000000 <.ARM.exidx.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE>:
   0:   00000000    andeq   r0, r0, r0
            0: R_ARM_PREL31 .text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE
            0: R_ARM_NONE   __aeabi_unwind_cpp_pr1
   4:   80000000    andhi   r0, r0, r0
            4: R_ARM_PREL31 .ARM.extab.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE

Not sure, but possibly the [Static Initialization Order Fiasco](https://isocpp.org/wiki/faq/ctors#static-init-order)? — Fred Larson, Aug 15 '16 at 18:28
It looks that you compile with more than one job. This could give output in different sequences, which the compiler may treat differently. — Emilio Pastor Mira, Aug 15 '16 at 18:30
@EmilioPastorMira what do you mean 'output in different sequences'? The compiler doesn't have memory: you invoke it, it takes your supplied info and then it goes away. No? — Bob, Aug 15 '16 at 18:31
If it is GCC based, you can try compiling with `-save-temps` and check the assembly output to see clearer what is changing. — rodrigo, Aug 15 '16 at 18:34
@Adrian I was thinking more about the linker, but I forgot that you only look at one object, sorry. — Emilio Pastor Mira, Aug 15 '16 at 18:38
I suppose it could be a compile time date/stamp/buld# macro that gets assigned to a literal value? — Galik, Aug 15 '16 at 19:22
@Galik I'm trying to get `objdump` working on it so I can see what item is assigned to that address. — Bob, Aug 16 '16 at 02:09
@Adrian Could you compile to assembly language and then compare the assembly outputs rather than the objects? — Galik, Aug 16 '16 at 04:40

gcc C++ compiler - obj file creation non-deterministic?

0 Answers0