search

STMicroelectronics / STM32CubeG0

STM32Cube MCU Full Package for the STM32G0 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
164 stars 75 forks source link

__RAM_FUNC breaks when inlined by GCC LTO #16

Open philiptaylor opened 3 years ago

philiptaylor commented 3 years ago

When GCC inlines functions, it ignores the section attribute of the inlined function. (This seems to be considered a feature, not a bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78903, etc)

Drivers/STM32G0xx_HAL_Driver/Inc/stm32g0xx_hal_def.h has:

#define __RAM_FUNC __attribute__((section(".RamFunc")))

This is used by FLASH_Program_Fast in stm32g0xx_hal_flash.c (which must run from RAM because it needs exclusive access to flash).

When compiling with LTO, GCC will inline functions across different source files. That means FLASH_Program_Fast may be inlined into the application code that calls it, which is typically not in .RamFunc, so the code will run from flash and will fail.

I believe the best way to fix this is with noinline, i.e.

#define __RAM_FUNC __attribute__((section(".RamFunc"), noinline))

Then the function won't be inlined and will remain in the correct section.

(With this change, I was able to successfully build my code with LTO (which significantly reduces code size) and haven't noticed any other problems.)

RKOUSTM commented 3 years ago

Hi @philiptaylor,

Thank you for your contribution. Your report will be forwarded to our development team. We will get back to you as soon as we have more details.

Thank you once more for this contribution.

With regards,

RKOUSTM commented 3 years ago

ST Internal Reference: 108546