LTO optimises out Hardware_init pointers

[ser-plu]

Building a project for STM32G431 with arm-none-eabi 11.3.

When enabling LTO optimisation, the pointers to hardware_init functions get optimised out: the .hardware_init section is empty (__hardware_init_start equals __hardware_init_end).

To preserve the pointers, __attribute__((used)) is required for the pointers.

This file should be corrected: https://github.com/modm-io/modm/blob/develop/src/modm/platform/core/cortex/hardware_init.hpp
like this:

#define MODM_HARDWARE_INIT(function) \
	modm_section(".hardware_init") \
	void* const MODM_CONCAT(__modm_hardware_init_ptr_, function) __attribute__((used) = (void*)&function

/// Call `function` during boot process with a unique name.
/// @hideinitializer
#define MODM_HARDWARE_INIT_NAME(name, function) \
	modm_section(".hardware_init") \
	void* const MODM_CONCAT(__modm_hardware_init_ptr_, name) __attribute__((used) = (void*)&function

/// Call `function` during boot process in a global order.
/// @hideinitializer
#define MODM_HARDWARE_INIT_ORDER(function, order) \
	modm_section(".hardware_init.order_" MODM_STRINGIFY(order)) \
	void* const MODM_CONCAT(__modm_hardware_init_ptr_, function) __attribute__((used) = (void*)&function

/// Call `function` during boot process in a global order with a unique name.
/// @hideinitializer
#define MODM_HARDWARE_INIT_NAME_ORDER(name, function, order) \
	modm_section(".hardware_init.order_" MODM_STRINGIFY(order)) \
	void* const MODM_CONCAT(__modm_hardware_init_ptr_, name) __attribute__((used) = (void*)&function

Or, probably, modm_used macro should be defined beforehand.

[ser-plu]

Also attribute((noinline)) should be added to the main function to have a valid breakpoint at debug..

[salkinium]

Ok, do you want to open a PR?

[salkinium]

In general, LTO can be a bit problematic with custom linkerscripts, and I'm not sure if the problems have been completely fixed yet. That's why it's disabled by default in modm.

[salkinium]

I also think that the .assertion section will suffer from the same problem, since it uses the same technique.

[ser-plu]

I also think that the .assertion section will suffer from the same problem, since it uses the same technique.

The assertion part already has used attribute

[salkinium]

Let me know if you find more linker related bugs with LTO enabled. Perhaps it's usable now and we can enable it by default.

[ser-plu]

Not sure, how this is related to LTO, but when I enable it ( -flto --specs=nano.specs --specs=nosys.specs ), the linker gives error

undefined reference to _sbrk_r'`

I don't understand, why the linker cannot use the _sbrk_r from heap_newlib.cpp or from no_heap.c any more. It apparently links memory allocation to the built-in version of _sbrk_r, which additionally requires end symbol specified in linker script.
If I specify end symbol and comment out modm::_sbrk_r, linker succeeds.

[ser-plu]

One last thing: when using static libraries, the solution described below is also required to be added to the main CMakeLists file

https://stackoverflow.com/questions/39236917/using-gccs-link-time-optimization-with-static-linked-libraries

[salkinium]

Oh, interesting. That's probably related to weak linking and perhaps the search order of symbols in static libraries?

We could definitely use some help with the CMake generator, it's very elusive and there are many subtle details that make it difficult to get just right.
So feel free to add LTO support as an option modm:build:lto to the build script generator modules. Otherwise the effort will get lost.

[ser-plu]

I created one more PR with all bugs that I found. I would expect more stuff to appear on other projects - I used only a limited set of features.

Sorry, but creating a new option is a bit out of my scope.