Hi all,
bit background what I’m trying to achieve. We want migrate from IAR workspace build system to CMake build system to make our builds more flexible. We have to stick with IAR compiler, at least for now. Target is to have identical binaries, in order to proof that IAR workspace can be safely replaced by CMake system.
What I achieved:
Nearly identical binaries. Only few Bytes difference when compared HEX -> most of compile and linker parameters are most probably fine
From functional point of view I do not see any differences, but still, binaries are not identical
What I want to achieve:
Identical binaries.
Here is detailed disassembly where differences are. I always compare CMake and IAR workspace results:
I can not upload example project or more pictures, since I’m newbie there. If needed, I think we can figure out how to share it.
Can anyone give me some kick what is that difference do and ideally how to deal with it? I think it is something related to linker, but not really sure.
That could be relocation differences? Are the intermediate .o files the same up to that point? That would at least narrow it down to the linker at which point dissecting the command lines in each would likely help. Could it be the order of objects on the link line perhaps?
Hi Ben,
the object files are not identical. I tried to compare them bit in detail, but too much changes.
But what hits me that in object file at header at 0x0020 value differs. In case of IAR workspace, there was 882E but in case of CMake there was 9D28. Maybe that make actual difference.
Determining what makes those differences is likely the first thing to look at. Comparing the compile line for that object would be the first place I’d look at least.
From someone who is converting their project from another build system. Trying to be exactly binary same isn’t how we are measuring a successful transition. And arguably can actually be a bad thing. It can result in people never switching because it’s not the exact same.
We are measuring our successful transition by our testing process. Not being exactly the binary same. If it passes all the same tests, QE, etc. Then we fully transition. Being binary same was such a bad goal it delayed our transition to a modern build system for years, and hurt the company.
Even if there’s not exact binary equivalence, the journey to understand the differences is, I think, useful. Determining it comes down to “preferred linker order” or “object file metadata” and brushing that away is fine, IMO. Discovering that your project is sensitive to such things is also useful knowledge.
Maybe I should explain bit more about this. We have to move to CMake, because current IAR workspace is not flexible for us. But we also need to understand what cause those differences to be sure it will not affect current functionality (for instance from timing point of view). Goal for now is to generate same binaries, but if they differ, it is OK if we will understand what differs and what are consequences.
Hi again,
so whole difference was caused by order files when linking. Changing order of source files simply solved issue and I could get identical HEX files
Different order caused different placement of static variables and that caused production of slightly different HEX files. This was not clear to me from disassembly to be honest.
Anyway thanks for help and have a great day!
Martin S.
