Skip to main content
K
KMcle.2
Visitor II
March 28, 2023
Question

Missing compiler options and output binary discrepancy

  • March 28, 2023
  • 1 reply
  • 1551 views

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/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127/tools/bin"

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

    This topic has been closed for replies.

    1 reply

    P
    Paolo ALBERELLI_O
    Visitor II
    March 28, 2023

    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 ?

    Terms & ConditionsAccessibility statement