0

I am facing an issue where the binary output of my STM32CubeIDE project built on Linux and Windows is inconsistent. I have installed STM32CubeIDE Version 1.6.1 and the fixed Toolchain: GNU Tools for STM32 (7-2018-q2-update) on both platforms. Upon comparing the makefiles, I found that they match, but the resulting binaries do not.

Can you suggest steps that I can take to ensure consistent binary output on both platforms? Additionally, which files should I compare to troubleshoot the issue?

Update: If I build the same source code on two different Windows machines, I get the same binary.

Update 2: I have created a basic stm32 project using only the code generated by CubeMX. I have observed that the binary output is identical when I compile the project on Windows and on Linux. This indicates that the toolchain is functioning correctly, and any differences observed are likely due to my own source code.

nza
  • 91
  • 5
  • Are the file sizes different? You can compare the `.list` files it probably generates. – pmacfarlane Mar 30 '23 at 17:11
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. – Blue Robin Mar 31 '23 at 03:17
  • @pmacfarlane thank you for your comment. The binary sizes are identical. In fact, there are differences in the `.list` file. I will check them and try to find the corresponding code. – nza Mar 31 '23 at 06:24
  • define binary as in binary size, the elf file format, etc no reason to assume those are the same and the same "binary" can have different elf information and result in a different size file you can take a perfectly fine elf file and strip information from it and still have a perfectly fine binary, different size, doesnt match. – old_timer Mar 31 '23 at 15:37
  • binaries matching even from the same tool, same day may not happen (dates and file paths get included in wrappers like elf. if you have file/attention type code then the path that it was built in goes into the binary itself making the same binary on the same machine on the same day/minute from a different directory not match each other. – old_timer Mar 31 '23 at 15:39
  • then two compilers on different systems, even if they are in theory the same compiler. it just snowballs from there. if you want help here then create a very small program perhaps even just main with a return zero, build it, hex dump both, cut and paste (NO PICTURES) of the source, the outputs and the differences in the question. otherwise the answer is: they are not expected to match. – old_timer Mar 31 '23 at 15:40
  • @old_timer, thank you for your comments. I don't use any `__FILE__`, `__DATE__`, `__TIME__` so the path and time should not get included in my .bin. – nza Apr 03 '23 at 09:22
  • @old_timer, I also built a minimal STM32 project on both platforms. In this case, the binaries do match. Therefore, there is definitely something in my source code which causes the mismatch between the binaries and not in the toolchain. – nza Apr 03 '23 at 09:27

1 Answers1

1

In general what you are hoping for is not possible with standard embedded tools.

Enabling reproducible builds is an active area of development in open source toolchains. I have personally given up on it (for now at least) in embedded projects.

Many reasons for non-determinism and steps to take against it are listed in the related question How to produce deterministic binary output with g++.

A common one I have found is different linking order on different platforms. Also, as soon as you change the linking order you introduce different amounts of padding, so not even the size will remain exactly the same.

Tom V
  • 4,827
  • 2
  • 5
  • 22
  • Thank you for your answer. The binaries match when I build the source code on different Windows machines. Therefore, it appears to be possible to build deterministic binaries with my toolchain. – nza Mar 31 '23 at 07:15
  • If I roll two dice and they come out the same that doesn't mean that a third one is guaranteed to as well. – Tom V Mar 31 '23 at 08:51