Czy rekompilacja programu daje identyczny plik binarny?

Gdybym miał skompilować program do pojedynczego pliku binarnego, zrobić sumę kontrolną, a następnie ponownie skompilować na tym samym komputerze z tymi samymi ustawieniami kompilatora i kompilatora oraz sumą kontrolną zrekompilowanego programu, czy suma kontrolna się nie powiedzie?

Jeśli tak, to dlaczego? Jeśli nie, czy posiadanie innego procesora skutkowałoby nieidentycznym plikiem binarnym?

1. Skompiluj ten sam program z tymi samymi ustawieniami na tym samym komputerze:

   Chociaż ostateczna odpowiedź brzmi „zależy”, uzasadnione jest oczekiwanie, że większość kompilatorów będzie deterministyczna przez większość czasu i że utworzone pliki binarne powinny być identyczne. Rzeczywiście, niektóre systemy kontroli wersji zależą od tego. Jednak zawsze są wyjątki; jest całkiem możliwe, że jakiś kompilator gdzieś zdecyduje się wstawić znacznik czasu lub coś takiego (na przykład iirc, Delphi). Lub sam proces kompilacji może to zrobić; Widziałem makefile dla programów w C, które ustawiają makro preprocesora na bieżący znacznik czasu. (Wydaje mi się, że byłoby to inne ustawienie kompilatora.)

   Pamiętaj również, że jeśli statycznie podłączysz plik binarny, wówczas skutecznie uwzględnisz stan wszystkich odpowiednich bibliotek na komputerze, a wszelkie zmiany w dowolnej z nich wpłyną również na twój plik binarny. Tak więc istotne są nie tylko ustawienia kompilatora.

2. Skompiluj ten sam program na innym komputerze z innym procesorem.

   Tutaj wszystkie zakłady są wyłączone. Większość nowoczesnych kompilatorów jest w stanie dokonywać optymalizacji specyficznych dla celu; jeśli ta opcja jest włączona, pliki binarne mogą się różnić, chyba że procesory są podobne (i nawet wtedy jest to możliwe). Zobacz także powyższą uwagę na temat łączenia statycznego: środowisko konfiguracyjne wykracza daleko poza ustawienia kompilatora. O ile nie masz bardzo ścisłej kontroli konfiguracji, jest bardzo prawdopodobne, że coś różni się między tymi dwiema maszynami.

To, o co pytasz, to „ deterministyczny wynik ”. Jeśli skompilowałeś program raz, natychmiast skompiluj go ponownie, prawdopodobnie uzyskasz ten sam plik wyjściowy. Jednak jeśli cokolwiek się zmieniło - nawet niewielka zmiana - szczególnie w komponencie, którego używa skompilowany program, to wyjście kompilatora może się również zmienić.

Czy rekompilacja programu daje identyczny plik binarny?

Dla wszystkich kompilatorów? Nie. Kompilator C # przynajmniej nie jest dozwolony.

Eric Lippert szczegółowo analizuje, dlaczego dane wyjściowe kompilatora nie są deterministyczne .

[T] Kompilator C # z założenia nigdy nie produkuje tego samego pliku binarnego dwa razy. Kompilator C # osadza świeżo wygenerowany identyfikator GUID w każdym zestawie za każdym razem, gdy go uruchamiasz, dzięki czemu nie ma dwóch identycznych zestawów. Cytat ze specyfikacji CLI:

Kolumna Mvid indeksuje unikalny identyfikator GUID [...] identyfikujący to wystąpienie modułu. [...] Mvid powinien być nowo wygenerowany dla każdego modułu [...] Podczas gdy sam [środowisko wykonawcze] nie korzysta z Mvid, inne narzędzia (takie jak debuggery [...]) polegają na tym, że Mvid prawie zawsze różni się w zależności od modułu.

Chociaż jest to specyficzne dla wersji kompilatora C #, wiele punktów w artykule można zastosować do dowolnego kompilatora.

Po pierwsze, zakładamy, że za każdym razem otrzymujemy tę samą listę plików, w tej samej kolejności. Ale w niektórych przypadkach dotyczy to systemu operacyjnego. Kiedy mówisz „csc * .cs”, kolejność, w jakiej system operacyjny wyświetla listę pasujących plików, jest szczegółem implementacji systemu operacyjnego; kompilator nie sortuje tej listy w kolejności kanonicznej.

• -frandom-seed=123kontroluje losowość wewnętrzną GCC. man gccmówi:

  Ta opcja zapewnia ziarno, którego GCC używa zamiast liczb losowych do generowania niektórych nazw symboli, które muszą być różne w każdym skompilowanym pliku. Służy również do umieszczania unikatowych znaczków w plikach danych zasięgu i plikach obiektów, które je wytwarzają. Możesz użyć opcji -frandom-seed, aby utworzyć odtwarzalnie identyczne pliki obiektowe.

• __FILE__: umieść źródło w stałym folderze (np. /tmp/build)

• na __DATE__, __TIME__, __TIMESTAMP__:
  • libfaketime: https://github.com/wolfcw/libfaketime
  • zastąp te makra za pomocą -D
  • -Wdate-timelub -Werror=date-time: ostrzegaj lub zawieść, jeśli albo __TIME__, __DATE__albo __TIMESTAMP__są używane. Jądro Linux 4.4 używa go domyślnie.
• użyj Dflagi z arlub użyj https://github.com/nh2/ar-timestamp-wiper/tree/master do wycierania znaczków
• -fno-guess-branch-probability: starsze wersje podręczników mówią, że jest to źródło niedeterminizmu, ale już nie . Nie jestem pewien, czy jest to objęte, -frandom-seedczy nie.

Debian Reproducible buduje próby standaryzacji pakietów Debiana bajt po bajcie, a ostatnio otrzymał grant Linux Foundation . Obejmuje to coś więcej niż tylko kompilację, ale powinno być interesujące.

Buildroot ma BR2_REPRODUCIBLEopcję, która może dać pewne pomysły na poziomie pakietu, ale na tym etapie nie jest jeszcze ukończona.

Powiązane wątki:

• /programming/14653874/deterministic-binary-output-with-g
• https://www.quora.com/What-can-be-the-possible-reasons-for-the-object-code-of-an-unchanged-C-file-to-change-on-recompilation

Projekt https://reproducible-builds.org/ dotyczy właśnie tego i stara się znaleźć odpowiedź na pytanie „nie, nie będą się różnić” w jak największej liczbie miejsc. NixOS i Debian mają teraz ponad 90% odtwarzalności swoich pakietów.

Jeśli skompilujesz plik binarny, a ja skompiluję plik binarny, a są one identyczne bit po bicie, to mogę być pewny, że kod źródłowy i narzędzia są tym, co określa dane wyjściowe, i że nie zakradłeś się po drodze kod trojana.

Jeśli połączymy odtwarzalność z możliwością rozruchu ze źródła czytelnego dla człowieka, jak działa http://bootstrappable.org/ , otrzymujemy system określony od podstaw przez źródło czytelne dla człowieka, i dopiero wtedy jesteśmy w punkcie, w którym możemy ufać, że wiemy, co robi system.

Powiedziałbym NIE, to nie jest w 100% deterministyczne. Wcześniej współpracowałem z wersją GCC, która generuje docelowe pliki binarne dla procesora Hitachi H8.

Nie ma problemu ze znacznikiem czasu. Nawet jeśli kwestia znacznika czasu zostanie zignorowana, określona architektura procesora może pozwolić na zakodowanie tej samej instrukcji na 2 nieco inne sposoby, przy czym niektóre bity mogą mieć wartość 1 lub 0. Moje wcześniejsze doświadczenia pokazują, że wygenerowane pliki binarne były w tej samej chwili WIĘCEJ ale czasami gcc generuje pliki binarne o identycznym rozmiarze, ale niektóre bajty różnią się tylko 1 bitem, np. 0XE0 staje się 0XE1.

Ogólnie nie. Najbardziej rozsądne kompilatory uwzględnią czas kompilacji w module obiektowym. Nawet jeśli zresetujesz zegar, musisz być bardzo dokładny w odniesieniu do momentu rozpoczęcia kompilacji (a następnie mieć nadzieję, że dostęp do dysku itp. Był taki sam jak wcześniej).