Showing results for 
Search instead for 
Did you mean: 

Missing compiler options and output binary discrepancy

Associate II

I noticed some descrpancy between the output binary from CubeIDE build and the VS Code build. While investigating this I noticed that there was some missing compiler options in the cmake file. The options missing are -fno-strict-aliasing from GCC compiler optimization settings, -mthumb, -fstack-usage, and -c.0693W00000aJoFDQA0.png0693W00000aJoR4QAK.png 

The flags and options in the cmake output files are,

0693W00000aJoT0QAK.png0693W00000aJoTtQAK.pngAfter rectifying the missing complier flags, I still notice that the output binary between VS Code and Cube IDE still do not match. 0693W00000aJocWQAS.pngAt this point, I'm not sure where the discrepancy is coming through. I have check that the same tool chain is being invoked in both scenarios, and have checked GG_COLLECT_OPTIONS for any discrepancies.


Toolchain VS Code: "C:/ST/STM32CubeIDE_1.10.1/STM32CubeIDE/plugins/"

Toolchain CubeIDE:

0693W00000aJoW9QAK.pngOptions for the c compiler in CubeIDE:

-mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F413xx -DDEBUG -c -I../Inc -I../Drivers/CMSIS/Include -I../Drivers/STM32F4xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F4xx/Include -I../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -I../rs1_drivers/inc -Ofast -ffunction-sections -fdata-sections -fno-strict-aliasing -Wall -fcommon -fstack-usage --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb

Associate II

At identical flags the produced binaries should differ only because of the link order.

CubeIDE's objects.list order is not identical to VS Code's st-project.cmake .

If you manually reorder the latter according for the former you should get the exact same binary.

I did try this a while back confirming the observation, but I haven't retried it recently.

I believe VS Code's importer strictly follows the .cproject order while CubeIDE sorts the source tree in a slightly different way.

Is it a strong requirement to have the exact same binary ?

If so, is manual rearrangement of st-project.cmake a suitable workaround ?