Việc biên dịch lại một chương trình có tạo ra một nhị phân giống hệt bit-bit không?

Nếu tôi biên dịch một chương trình thành một nhị phân đơn, tạo một tổng kiểm tra, sau đó biên dịch lại nó trên cùng một máy với cùng cài đặt trình biên dịch và trình biên dịch và kiểm tra lại chương trình được biên dịch lại, liệu tổng kiểm tra có thất bại không?

Nếu vậy, tại sao lại thế này? Nếu không, việc có một CPU khác dẫn đến nhị phân không giống nhau?

1. Biên dịch cùng một chương trình với cùng các cài đặt trên cùng một máy:

   Mặc dù câu trả lời dứt khoát là "nó phụ thuộc", thật hợp lý khi hy vọng rằng hầu hết các trình biên dịch sẽ có tính xác định trong hầu hết thời gian và các nhị phân được tạo ra phải giống hệt nhau. Thật vậy, một số hệ thống kiểm soát phiên bản phụ thuộc vào điều này. Tuy nhiên, luôn có những trường hợp ngoại lệ; hoàn toàn có khả năng một số trình biên dịch ở đâu đó sẽ quyết định chèn dấu thời gian hoặc một số thứ tương tự (ví dụ: iirc, Delphi chẳng hạn). Hoặc chính quá trình xây dựng có thể làm điều đó; Tôi đã thấy các tệp tạo tệp cho các chương trình C đặt macro tiền xử lý thành dấu thời gian hiện tại. (Tuy nhiên, tôi đoán đó sẽ được coi là một cài đặt trình biên dịch khác.)

   Ngoài ra, hãy lưu ý rằng nếu bạn liên kết tĩnh nhị phân, thì bạn đang kết hợp hiệu quả trạng thái của tất cả các thư viện có liên quan trên máy của mình và mọi thay đổi trong bất kỳ một trong số đó cũng sẽ ảnh hưởng đến nhị phân của bạn. Vì vậy, nó không chỉ là cài đặt trình biên dịch có liên quan.

2. Biên dịch cùng một chương trình trên một máy khác với CPU khác.

   Ở đây, tất cả các cược đã tắt. Hầu hết các trình biên dịch hiện đại có khả năng thực hiện tối ưu hóa mục tiêu cụ thể; nếu tùy chọn này được bật, thì các nhị phân có thể sẽ khác đi trừ khi các CPU tương tự nhau (và thậm chí sau đó, điều đó là có thể). Ngoài ra, hãy xem lưu ý ở trên về liên kết tĩnh: môi trường cấu hình vượt xa các cài đặt trình biên dịch. Trừ khi bạn có kiểm soát cấu hình rất nghiêm ngặt, rất có thể sẽ có thứ gì đó khác nhau giữa hai máy.

Những gì bạn đang hỏi là "là đầu ra xác định ." Nếu bạn biên dịch chương trình một lần, ngay lập tức biên dịch lại, có thể bạn sẽ kết thúc với cùng một tệp đầu ra. Tuy nhiên, nếu có bất cứ điều gì thay đổi - ngay cả một thay đổi nhỏ - đặc biệt là trong một thành phần mà chương trình đã biên dịch sử dụng, thì đầu ra của trình biên dịch cũng có thể thay đổi.

Việc biên dịch lại một chương trình có tạo ra một nhị phân giống hệt bit-bit không?

Đối với tất cả các trình biên dịch? Không. Trình biên dịch C #, ít nhất, không được phép.

Eric Lippert đã phân tích rất kỹ về lý do tại sao đầu ra của trình biên dịch không mang tính quyết định .

[T] anh trình biên dịch C # theo thiết kế không bao giờ tạo ra cùng một nhị phân hai lần. Trình biên dịch C # nhúng GUID mới được tạo trong mỗi hội đồng, mỗi khi bạn chạy nó, do đó đảm bảo rằng không có hai hội đồng nào giống nhau từng bit một. Để trích dẫn từ đặc tả CLI:

Cột Mvid sẽ lập chỉ mục GUID duy nhất [...] xác định phiên bản này của mô-đun. [...] Mvid nên được tạo mới cho mọi mô-đun [...] Mặc dù [thời gian chạy] không sử dụng Mvid, các công cụ khác (như trình gỡ lỗi [...]) dựa vào thực tế là Mvid hầu như luôn luôn khác nhau từ mô-đun này sang mô-đun khác.

Mặc dù nó dành riêng cho một phiên bản của trình biên dịch C #, nhiều điểm trong bài viết có thể được áp dụng cho bất kỳ trình biên dịch nào .

Trước hết, chúng tôi giả định rằng chúng tôi luôn nhận được cùng một danh sách các tệp mỗi lần, theo cùng một thứ tự. Nhưng đó là trong một số trường hợp cho đến hệ điều hành. Khi bạn nói "csc * .cs", thứ tự mà hệ điều hành cung cấp danh sách các tệp phù hợp là một chi tiết triển khai của hệ điều hành; trình biên dịch không sắp xếp danh sách đó thành một thứ tự chính tắc.

• -frandom-seed=123kiểm soát một số ngẫu nhiên nội bộ GCC. man gccnói:

  Tùy chọn này cung cấp một hạt giống mà GCC sử dụng thay cho các số ngẫu nhiên trong việc tạo các tên ký hiệu nhất định phải khác nhau trong mỗi tệp được biên dịch. Nó cũng được sử dụng để đặt tem độc đáo trong các tệp dữ liệu bảo hiểm và các tệp đối tượng tạo ra chúng. Bạn có thể sử dụng tùy chọn -frandom-seed để tạo các tệp đối tượng giống hệt nhau.

• __FILE__: đặt nguồn vào một thư mục cố định (ví dụ /tmp/build)

• cho __DATE__, __TIME__, __TIMESTAMP__:
  • libfaketime: https://github.com/wolfcw/libfaketime
  • ghi đè các macro đó bằng -D
  • -Wdate-timehoặc -Werror=date-time: cảnh báo hay thất bại nếu một trong hai __TIME__, __DATE__hoặc __TIMESTAMP__là được sử dụng. Linux kernel 4.4 sử dụng nó theo mặc định.
• sử dụng Dcờ với arhoặc sử dụng https://github.com/nh2/ar-timestamp-wiper/tree/master để xóa tem
• -fno-guess-branch-probability: các phiên bản thủ công cũ hơn nói rằng đó là một nguồn không xác định, nhưng không còn nữa . Không chắc chắn nếu điều này được bao phủ bởi -frandom-seedhay không.

Dự án xây dựng lại bản sao Debian cố gắng chuẩn hóa các gói Debian theo từng byte và gần đây đã nhận được một khoản tài trợ Linux Foundation . Điều đó bao gồm nhiều hơn là chỉ biên dịch, nhưng nó nên được quan tâm.

Buildroot có một BR2_REPRODUCIBLEtùy chọn có thể đưa ra một số ý tưởng ở cấp độ gói, nhưng nó vẫn chưa hoàn thành vào thời điểm này.

Chủ đề liên quan:

• https://stackoverflow.com/questions/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

Tôi nói KHÔNG, nó không mang tính quyết định 100%. Trước đây tôi đã làm việc với một phiên bản GCC để tạo các nhị phân đích cho bộ xử lý Hitachi H8.

Nó không phải là một vấn đề với dấu thời gian. Ngay cả khi vấn đề về dấu thời gian bị bỏ qua, kiến ​​trúc bộ xử lý cụ thể có thể cho phép cùng một lệnh được mã hóa theo 2 cách hơi khác nhau trong đó một số bit có thể là 1 hoặc 0. Kinh nghiệm trước đây của tôi cho thấy các nhị phân được tạo ra là cùng MOST của thời gian nhưng đôi khi gcc sẽ tạo ra các nhị phân có kích thước giống hệt nhau nhưng một số byte chỉ khác nhau 1 bit, ví dụ 0XE0 trở thành 0XE1.

Dự án https://reproducible-builds.org/ là tất cả về điều này, và đang cố gắng hết sức để đưa ra câu trả lời cho câu hỏi của bạn "không, chúng sẽ không khác nhau" ở càng nhiều nơi càng tốt. NixOS và Debian hiện có khả năng tái tạo hơn 90% cho các gói của họ.

Nếu bạn biên dịch nhị phân và tôi biên dịch nhị phân, và chúng giống hệt nhau từng bit, thì tôi có thể yên tâm rằng mã nguồn và các công cụ là yếu tố quyết định đầu ra và bạn không lén lút mã trojan trên đường đi.

Nếu chúng ta kết hợp khả năng tái tạo với khả năng khởi động từ nguồn có thể đọc được của con người, vì http://bootstrappable.org/ đang thực hiện, chúng ta sẽ có một hệ thống được xác định từ nguồn gốc có thể đọc được từ con người, và chỉ khi đó chúng ta mới ở điểm chúng ta có thể tin tưởng rằng chúng ta biết hệ thống đang làm gì.

Nói chung, không. Các trình biên dịch hợp lý nhất sẽ bao gồm thời gian biên dịch trong mô đun đối tượng. Ngay cả khi bạn đã thiết lập lại đồng hồ, bạn phải rất chính xác về thời điểm bạn khởi động trình biên dịch (và sau đó hy vọng rằng các truy cập đĩa, v.v., có cùng tốc độ như trước).