Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resulting binaries: Exactly same code produces very different resulting binaries (IDFGH-6323) #7985

Closed
carlessole opened this issue Dec 1, 2021 · 6 comments
Assignees
Labels
Awaiting Response awaiting a response from the author Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@carlessole
Copy link

  • Module or chip used: ESP32-WROVER (With ESP_PROG)
  • IDF version: v4.3.1
  • Build System: CMake/idf.py (usingEclipse Plugin)
  • Compiler version: esp-2020r3-8.4.0
  • Operating System: Windows
  • (Windows only) environment type: -.
  • Using an IDE?: Yes. Eclipse + ESP-IDF plugin, but also thorugh CLI
  • Power Supply: USB

Hi everyone,
I have noticed a behaviour that it is not what I thought it was correct.

When I compile multiple times exactly the same source code. The resulting binaries:

  1. Sometimes are almost the same, in exception of the compile date/time and some final CRC. That is the behaviour that I expect.
  2. Sometimes the resulting binaries are very very different even the size is not the same (just few bytes). That is the behaviour that I don't understand. Is that correct? Why is happening?

I was expecting always the 1st case because then it is easier to probe that both binaries have been created from the same source code.

Here I attach some images when compilation differs a lot:
1_verydifferent_datetime
2_verydifferent
3_verydifferent
4_verydifferent

@espressif-bot espressif-bot added the Status: Opened Issue is new label Dec 1, 2021
@github-actions github-actions bot changed the title Resulting binaries: Exactly same code produces very different resulting binaries Resulting binaries: Exactly same code produces very different resulting binaries (IDFGH-6323) Dec 1, 2021
@negativekelvin
Copy link
Contributor

esp-idf/Kconfig

Lines 204 to 209 in 9919b75

config APP_REPRODUCIBLE_BUILD
bool "Enable reproducible build"
default n
select COMPILER_HIDE_PATHS_MACROS
help
If enabled, all date, time, and path information would be eliminated.

@igrr
Copy link
Member

igrr commented Dec 1, 2021

Linking #5251 and #5873.

I think in 4.3 this might be a regression in the linker script generator, where on different runs it may produce different order of libraries. This should be fixed in 404ee09, will be part of the next v4.3.2 bugfix release.

Additionally in release/v4.4 there is a new option CONFIG_APP_REPRODUCIBLE_BUILD which @negativekelvin has kindly linked above, it will also make ELF files identical across builds, so event the ELF SHA256 value in binary image header will be stable.

@carlessole
Copy link
Author

Thanks @igrr amd @negativekelvin ,

@negativekelvin : I'm using v4.3.1 and so I have not that config field avialble. Moreover I'm ok that few things as paths, and date/time differs. But I see so many changes apart from these ones

@igrr : I think that my problem is probably related with the linker issue. I will try when v4.3.2 comes out to test it.

Thanks

@igrr
Copy link
Member

igrr commented Dec 21, 2021

@carlessole v4.3.2 has been released, please give it a try and see if this issue is fixed for you.

@Alvin1Zhang Alvin1Zhang added the Awaiting Response awaiting a response from the author label Dec 22, 2021
@Alvin1Zhang
Copy link
Collaborator

@carlessole Thanks for reporting, would you please help a try with the newly released IDF v4.3.2 and share any updates? Thanks.

@Alvin1Zhang
Copy link
Collaborator

@carlessole Thanks for reporting, will close due to short of feedback, feel free to reopen with more updates. Thanks.

@espressif-bot espressif-bot added Resolution: Done Issue is done internally Status: Done Issue is done internally and removed Status: Opened Issue is new labels Mar 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Response awaiting a response from the author Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

6 participants