GNU arm embedded toolchain 7-2017-q4 does not resolve linking to correct standard libraries when compiling for hardware floating point .

[Dag Midling Larsen]

Hi

I'm using these compiler flags.
-mcpu=cortex-m7 -mthumb -mfloat-abi=hard

Then adding --verbose to the linker options shows that the linker does not pick the correct libraries (not using libraries in the "hard" folders).

Best Regards,
Dag

[Tejas Belagod (belagod-tejas)]

Have you tried with -mfpu option?

$ arm-none-eabi-gcc -mcpu=cortex-m7 -mfloat-abi=hard -mthumb -mfpu=fpv5-d16 --print-multi-directory
thumb/v7e-m/fpv5/hard

[Dag Midling Larsen (dml)]

Hi

Thanks for your reply!

If I add "--print-multi-directory thumb/v7e-m/fpv5/hard" as specified by you I get an error on the last part.
As far as I understand --print-multi-directory is "diagnostic", that is it will show output.
I removed that last part as shown in attached LedBlinkHardFp_print_multi_directory.log, and then " thumb/v7e-m/fpv5/hard" is output by the compiler.
The strange thing is that the object files are not created with this option (at least not where I expect to find them).

Also attached is the log when only adding -mfpu=fpv5-d16.
This didn't help.
Note that I also have this issue with the previous major version of the toolchain.
Do you know a version that is known to work in this area?

Best Regards,
Dag

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Tejas Belagod
Sent: Friday, February 09, 2018 11:30 AM
To: Dag Midling Larsen <email address hidden>
Subject: [Ext] [Bug 1748410] Re: GNU arm embedded toolchain 7-2017-q4 does not resolve linking to correct standard libraries when compiling for hardware floating point .

Have you tried with -mfpu option?

$ arm-none-eabi-gcc -mcpu=cortex-m7 -mfloat-abi=hard -mthumb -mfpu=fpv5-d16 --print-multi-directory thumb/v7e-m/fpv5/hard

--
You received this bug notification because you are subscribed to the bug report.
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_bugs_1748410&d=DwIFaQ&c=uGuXJ43KPkPWEl2imVFDmZQlhQUET7pVRA2PDIOxgqw&r=Vg4T8mXfM5rIsipcm2GiWw&m=obEs0pLBxBPLrjimqmjsAD0ubWLWbNFJ1EVs1kn26No&s=o3ZaVgfd2r4pq_4oHj8uprJ8DIXzLrBclo-ovz3EeOk&e=

Title:
  GNU arm embedded toolchain 7-2017-q4 does not resolve linking to
  correct standard libraries when compiling for hardware floating point
  .

Status in GNU Arm Embedded Toolchain:
  New

Bug description:
  Hi

  I'm using these compiler flags.
  -mcpu=cortex-m7 -mthumb -mfloat-abi=hard

  Then adding --verbose to the linker options shows that the linker does
  not pick the correct libraries (not using libraries in the "hard"
  folders).

  Best Regards,
  Dag

To manage notifications about this bug go to:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_gcc-2Darm-2Dembedded_-2Bbug_1748410_-2Bsubscriptions&d=DwIFaQ&c=uGuXJ43KPkPWEl2imVFDmZQlhQUET7pVRA2PDIOxgqw&r=Vg4T8mXfM5rIsipcm2GiWw&m=obEs0pLBxBPLrjimqmjsAD0ubWLWbNFJ1EVs1kn26No&s=6UejSH-7g0kkRPms1k0Mc1XNSqpUmzwEadF0V_KCL8I&e=

[Tejas Belagod (belagod-tejas)]

I used --print-multi-directory to show you that the right directory is selected. 'thumb/v7e-m/fpv5/hard' is the output of --print-multi-directory, not a parameter to the option - hence shown on the next line in my reply above.

If you want objects/images to be created you will need to remove the --print-multi-directory option and provide the srcs etc with the right options to create the binary output.

[Thomas Preud'homme (thomas-preudhomme)]

Hi,

The output you have when using -print-multi-directory shows that the compiler would select a hardfloat multilib *if* the same options are passed when linking. The same options needs to be passed to GCC both when compiling and when linking. When compiling it ensures the files are actually compiled with floating-point instructions. When linking it ensures the linker is passed the corresponding multilib.

Best regards.

[Dag Midling Larsen (dml)]

Thanks a lot!
This made me understand that I should add -mfpu=fpv5-d16 BEFORE the comma separated linker options started with -Wl.
Then it links.
Thanks again!

1> c:\gnuarm2017q4/bin/arm-none-eabi-g++.exe -o Debug/LedBlinkHardFp.elf -mfpu=fpv5-d16 -Wl,-gc-sections,--verbose --specs=nano.specs -TC:\Users\DLarsen2\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32/STM32F7xxxx/LinkerScripts/STM32F769NI_flash.lds -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -Wl,--start-group Debug/startup_stm32f769xx.o Debug/stm32f7xx_hal.o Debug/stm32f7xx_hal_adc.o Debug/stm32f7xx_hal_adc_ex.o Debug/stm32f7xx_hal_can.o Debug/stm32f7xx_hal_cec.o Debug/stm32f7xx_hal_cortex.o Debug/stm32f7xx_hal_crc.o Debug/stm32f7xx_hal_crc_ex.o Debug/stm32f7xx_hal_cryp.o Debug/stm32f7xx_hal_cryp_ex.o Debug/stm32f7xx_hal_dac.o Debug/stm32f7xx_hal_dac_ex.o Debug/stm32f7xx_hal_dcmi.o Debug/stm32f7xx_hal_dcmi_ex.o Debug/stm32f7xx_hal_dfsdm.o Debug/stm32f7xx_hal_dma.o Debug/stm32f7xx_hal_dma2d.o Debug/stm32f7xx_hal_dma_ex.o Debug/stm32f7xx_hal_dsi.o Debug/stm32f7xx_hal_eth.o Debug/stm32f7xx_hal_flash.o Debug/stm32f7xx_hal_flash_ex.o Debug/stm32f7xx_hal_gpio.o Debug/stm32f7xx_hal_hash.o Debug/stm32f7xx_hal_hash_ex.o Debug/stm32f7xx_hal_hcd.o Debug/stm32f7xx_hal_i2c.o Debug/stm32f7xx_hal_i2c_ex.o Debug/stm32f7xx_hal_i2s.o Debug/stm32f7xx_hal_irda.o Debug/stm32f7xx_hal_iwdg.o Debug/stm32f7xx_hal_jpeg.o Debug/stm32f7xx_hal_lptim.o Debug/stm32f7xx_hal_ltdc.o Debug/stm32f7xx_hal_ltdc_ex.o Debug/stm32f7xx_hal_mdios.o Debug/stm32f7xx_hal_nand.o Debug/stm32f7xx_hal_nor.o Debug/stm32f7xx_hal_pcd.o Debug/stm32f7xx_hal_pcd_ex.o Debug/stm32f7xx_hal_pwr.o Debug/stm32f7xx_hal_pwr_ex.o Debug/stm32f7xx_hal_qspi.o Debug/stm32f7xx_hal_rcc.o Debug/stm32f7xx_hal_rcc_ex.o Debug/stm32f7xx_hal_rng.o Debug/stm32f7xx_hal_rtc.o Debug/stm32f7xx_hal_rtc_ex.o Debug/stm32f7xx_hal_sai.o Debug/stm32f7xx_hal_sai_ex.o Debug/stm32f7xx_hal_sd.o Debug/stm32f7xx_hal_sdram.o Debug/stm32f7xx_hal_smartcard.o Debug/stm32f7xx_hal_smartcard_ex.o Debug/stm32f7xx_hal_spdifrx.o Debug/stm32f7xx_hal_spi.o Debug/stm32f7xx_hal_sram.o Debug/stm32f7xx_hal_tim.o Debug/stm32f7xx_hal_tim_ex.o Debug/stm32f7xx_hal_uart.o Debug/stm32f7xx_hal_usart.o Debug/stm32f7xx_hal_wwdg.o Debug/stm32f7xx_ll_fmc.o Debug/stm32f7xx_ll_sdmmc.o Debug/stm32f7xx_ll_usb.o Debug/LEDBlink.o Debug/system_stm32f7xx.o -Wl,--end-group
1> GNU ld (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 2.29.51.20171128

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Thomas Preud'homme
Sent: Friday, February 09, 2018 12:44 PM
To: Dag Midling Larsen <email address hidden>
Subject: [Ext] [Bug 1748410] Re: GNU arm embedded toolchain 7-2017-q4 does not resolve linking to correct standard libraries when compiling for hardware floating point .

Hi,

The output you have when using -print-multi-directory shows that the compiler would select a hardfloat multilib *if* the same options are passed when linking. The same options needs to be passed to GCC both when compiling and when linking. When compiling it ensures the files are actually compiled with floating-point instructions. When link...

[Thomas Preud'homme (thomas-preudhomme)]

Closing as invalid since it seems to be working with the right options. Thanks for letting us know Dag!