Чи виробляє перекомпіляція програми біт-біт ідентичний бінарний файл?

Якби я скомпілював програму в один двійковий файл, зробив контрольну суму, а потім перекомпілював її на одній машині з тими ж налаштуваннями компілятора та компілятора та контрольною сумою перекомпільованої програми, чи буде контрольна сума невдалою?

Якщо так, то чому це? Якщо ні, то чи мати інший процесор призведе до неідентичного бінарного файлу?

1. Скомпілюйте ту ж програму з тими ж налаштуваннями на одній машині:

   Хоча остаточна відповідь - "це залежить", розумно очікувати, що більшість компіляторів буде детермінованою більшу частину часу, а створені двійкові файли повинні бути ідентичними. Дійсно, деякі системи управління версіями залежать від цього. І все-таки завжди є винятки; то цілком можливо , що деякі компілятор де - то вирішить вставити мітку або деякі такі (IIRC, Delphi робить, наприклад). Або сам процес збирання може це зробити; Я бачив makefiles для програм C, які встановлюють макрос препроцесора на поточну часову позначку. (Я думаю, що це вважатиметься різним параметром компілятора.)

   Також майте на увазі, що якщо ви стаціонарно зв’язуєте двійкове, ви фактично включаєте стан усіх відповідних бібліотек на вашій машині, і будь-яка зміна будь-якої з них також вплине на ваш двійковий файл. Тож актуальні не лише налаштування компілятора.

2. Скомпілюйте ту саму програму на іншій машині з іншим процесором.

   Тут усі ставки відключені. Більшість сучасних компіляторів здатні робити оптимізацію, орієнтовану на ціль; якщо цей параметр увімкнено, то ймовірні файли можуть відрізнятися, якщо процесори не схожі (і навіть тоді це можливо). Також див. Вищенаведене зауваження про статичне з'єднання: середовище конфігурації виходить далеко за рамки параметрів компілятора. Якщо у вас дуже жорсткий контроль конфігурації, то надзвичайно ймовірно, що між двома машинами щось відрізняється.

Що ви запитуєте, це " детермінований вихід ". Якщо ви скомпілювали програму один раз, негайно скомпілювали її ще раз, ви, ймовірно, отримаєте той самий вихідний файл. Однак якщо щось змінилося - навіть невелика зміна - особливо в компоненті, який використовує компільована програма, то вихід компілятора також може змінитися.

Чи виробляє перекомпіляція програми біт-біт ідентичний бінарний файл?

Для всіх компіляторів? Ні, компілятор C #, принаймні, заборонено.

Ерік Ліпперт дуже глибоко розбив про те, чому вихід компілятора не є детермінованим .

[T] компілятор C # за дизайном ніколи не видає один і той же двійковий файл двічі. Компілятор C # вбудовує щойно сформований GUID у кожну збірку кожного разу, коли ви запускаєте його, тим самим гарантуючи, що жодна дві збірки ніколи не бувають однаковими. Для цитування із специфікації CLI:

Стовпчик Mvid повинен індексувати унікальний GUID [...], який ідентифікує цей примірник модуля. [...] Mvid повинен бути новоствореним для кожного модуля [...] Хоча сам режим виконання не використовує Mvid, інші інструменти (наприклад, налагоджувачі [...]) покладаються на те, що Mvid майже завжди відрізняється від одного модуля до іншого.

Хоча це стосується і версії компілятора C #, багато пунктів статті можуть бути застосовані до будь-якого компілятора.

По-перше, ми припускаємо, що ми завжди отримуємо один і той же список файлів кожного разу в тому ж порядку. Але це в деяких випадках залежить від операційної системи. Коли ви говорите "csc * .cs", порядок, в якому операційна система записує список відповідних файлів, - це деталь реалізації операційної системи; компілятор не сортує цей список у канонічному порядку.

• -frandom-seed=123контролює деяку внутрішню випадковість GCC. man gccкаже:

  Ця опція забезпечує насіння, яке GCC використовує замість випадкових чисел для генерування певних імен символів, які мають бути різними у кожному складеному файлі. Він також використовується для розміщення унікальних штампів у файлах даних покриття та файлах об'єктів, які їх виробляють. Ви можете використовувати опцію -frandom-seed для створення відтворюваних ідентичних файлів об'єктів.

• __FILE__: покладіть джерело у фіксовану папку (наприклад /tmp/build)

• для __DATE__, __TIME__, __TIMESTAMP__:
  • libfaketime: https://github.com/wolfcw/libfaketime
  • замініть ці макроси -D
  • -Wdate-timeабо -Werror=date-time: попередити або , якщо не в змозі або __TIME__, __DATE__або __TIMESTAMP__є використовується. Ядро Linux 4.4 використовує його за замовчуванням.
• використовуйте Dпрапор за допомогою arабо використовуйте https://github.com/nh2/ar-timestamp-wiper/tree/master, щоб стерти штампи
• -fno-guess-branch-probability: старіші ручні версії кажуть, що це джерело недетермінізму, але вже не . Не впевнений, охоплює це -frandom-seedчи ні.

Debian Reproducible будує спроби проекту стандартизувати пакети Debian по байтах, і нещодавно отримав грант Linux Foundation . Це включає більше, ніж просто компіляцію, але це повинно зацікавити.

У Buildroot є BR2_REPRODUCIBLEваріант, який може дати деякі ідеї на рівні пакету, але це ще далеко не завершено.

Пов'язані теми:

• /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

Проект https://reproducible-builds.org/ про все це і намагається зробити відповідь на ваше запитання "ні, вони не будуть відрізнятися" в якомога більшій кількості місць. В даний час NixOS та Debian відтворюють понад 90% відтворюваності своїх пакетів.

Якщо ви компілюєте двійковий файл, а я складаю двійкове, і вони біт-на-біт однакові, то я можу переконатись, що вихідний код та інструменти визначають вихід, і що ви не прокрадалися в деяких троянський код по дорозі.

Якщо ми поєднуємо відтворюваність із завантажувальною здатністю з людського читаного джерела, як http://bootstrappable.org/ працює над цим, ми отримуємо систему, визначену з нуля джерелом, зрозумілим для людини, і лише тоді ми знаходимось у точці, де ми можемо вірити, що ми знаємо, що робить система.

Я б сказав, ні, це не на 100% детерміновано. Раніше я працював з версією GCC, яка генерує цільові бінарні файли для процесора Hitachi H8.

Це не проблема з позначкою часу. Навіть якщо проблема з марками часу ігнорується, конкретна архітектура процесора може дозволити кодування однієї і тієї ж інструкції двома дещо різними способами, де деякі біти можуть бути 1 або 0. Мій попередній досвід показує, що згенеровані бінарні файли були однаковими МОСТО часу але іноді gcc генерує бінарні файли однакового розміру, але деякі байти відрізняються лише на 1 біт, наприклад 0XE0 стає 0XE1.

Загалом, ні. Більшість досить складних компіляторів включатиме час компіляції в об'єктний модуль. Навіть якби ви скинули годинник, вам довелося б бути дуже точними щодо того, коли ви розпочали компіляцію (і тоді сподіваєтесь, що доступ до диска тощо повинен бути такою ж швидкістю, як і раніше).