2

I reformatted my code base with rustfmt 0.4.1-stable and had a huge diff that is hard to check by eye.

A long time ago, I had a similar problem after cargo fmt produced a huge diff. At that time, I solved it by:

cargo build --release
strip -s target/release/mylib.so -o target/release/mylib-stripped.so
diff <(hexdump -C < target/release/mylib-stripped.so) <(hexdump -C < target/release/prev-mylib-stripped.so)

The difference was just few bytes and looked like a time stamp, but this time the difference between both hexdump / objdump outputs is huge.

The code is different, for example:

                                        push   %r13
   188d3a:      41 54                   push   %r12
   188d3c:      53                      push   %rbx
-  188d3d:      48 81 ec 48 01 00 00    sub    $0x148,%rsp
-  188d44:      48 89 d3                mov    %rdx,%rbx
...
+  188d3d:      48 81 ec 88 06 00 00    sub    $0x688,%rsp
+  188d44:      4d 89 ce                mov    %r9,%r14
+  188d47:      4c 89 85 a0 fe ff ff    mov    %r8,-0x160(%rbp)
...

How do I make builds reproducible before and after cargo fmt?

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
user1244932
  • 7,352
  • 5
  • 46
  • 103
  • 3
    That shouldn't happen... [mcve] ? – Stargateur May 13 '18 at 08:25
  • 1
    Is your binary *already* reproducible? Are you sure you aren't confusing the result of non-deterministic builds with rustfmt? Perhaps you changed your dependencies or your compiler version, or perhaps the build is multithreaded or otherwise nondeterministic? – Shepmaster May 13 '18 at 16:17
  • @Shepmaster About only rustfmt I am sure. And my build multithread, but why multithread produce not determenistic code (without several cores I will perhaps wait forever for rebuild)? At now my version is that I have too many `assert!`, and after rustfmt too many lines change numbers, so every `assert!` transfered to inline code looks different. – user1244932 May 13 '18 at 17:50

0 Answers0