GCC ffreestanding and nolibc flags are ignored

[APort]

Hello,

We are trying to create a bear-metal project for ST MCU.

However, I noticed that no matter what, the GCC will still link libc and libm even if it is explicitly asked not to.

Its the same behavior from STM32CubeIDE and command line directly.

For example following linker command will happily load libm and libc - please see below.

It happens in latest toolchain com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.linux64_1.5.0.202011040924

and also in com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update release.

Please advice,

Thanks in advance

-------------------------------------------------------

arm-none-eabi-gcc -T ./stm.ld  --entry Reset_Handler
-ffreestanding -nostdlib -nostartfiles -nolibc -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -Wl,--verbose 
-o out.elf test.o
 
GNU ld (GNU Tools for STM32 9-2020-q2-update.20201001-1621) 2.34.0.20200428
....
...
../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a succeeded../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a
(/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a)lib_a-abort.o
(/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a)lib_a-abs.o
...
attempt to open ../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a succeeded../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a
(../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a)lib_a-s_ceil.o

[KnarfB]

Does it depend on the content of test.c or how test.o was compiled?

Works here under Win 10 with an empty Reset_Handler function and

PATH=C:\ST\STM32CubeIDE\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_1.5.0.202011040924\tools\bin\
arm-none-eabi-gcc -T ./test.ld --entry Reset_Handler ^
-ffreestanding -nostdlib -nostartfiles -nolibc ^
-mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -Wl,--verbose ^
-o out.elf test.c

[APort]

After investing more time and reducing the project to really minimal module, I found out what cases this behavior ...

Not what I would expect, but having DISCARD mentioning those libs inside LD file cases linker to include them.

Once you remove it, it behaves as expected (aka, no external linked libs).

/DISCARD/ :
{
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
}