Ref. #926. Fixes for LTO build. #928
Conversation
Co-authored-by: Raphael Lehmann <raphael@rleh.de>
|
Thanks! I'll wait another day, maybe something else pops up during more testing. |
| @@ -33,7 +33,7 @@ typedef void (* const FunctionPointer)(void); | |||
| extern uint32_t __main_stack_top[]; | |||
|
|
|||
| // Define the vector table | |||
| modm_section(".vector_rom") | |||
| modm_section(".vector_rom") modm_used | |||
There was a problem hiding this comment.
probably also necessary for vectorsRam just below.
Basically everything that's implicitly linked needs to be marked as used? Seems like a lot of work…
There was a problem hiding this comment.
Can you perhaps extract the symbols of the resulting ELF files with/without LTO and diff them? That would perhaps give you a more definitive list of lost symbols.
It's scons symbols but we seem to not have it for CMake.
Otherwise try: arm-none-eabi-nm -S -C --size-sort -td file.elf
There was a problem hiding this comment.
I don't see much difference any more. vectorsRam indeed is required to be used, I just use the ROM-mapped vector table in my project.
One more symbol missing is modm_abandon, but I think it is just optimised out as an empty function.
There was a problem hiding this comment.
Maybe, Undefined_Handler also requires the attribute. But I am not 100% sure
There was a problem hiding this comment.
I'll have a look myself tomorrow to check if we can enable LTO by default at least for the release build.
| @@ -19,7 +19,7 @@ void __modm_initialize_memory(void) | |||
| } | |||
|
|
|||
| // ---------------------------------------------------------------------------- | |||
| modm_weak modm_section("{{ no_heap_section }}") | |||
| modm_weak modm_used modm_section("{{ no_heap_section }}") | |||
There was a problem hiding this comment.
Wouldn't that always trigger the warning of the heap module not being included even if heap is not used in the application code?
There was a problem hiding this comment.
When heap is used, no_heap.cpp is excluded from build, isn't it?
There was a problem hiding this comment.
Yeah, but if heap is not used, then this weak _sbrk_r acts as a "canary function" that the linker tries to link if someone tries to use malloc (which internally calls _sbrk_r via Newlib.
This function is normally garbage collected by the linker because nobody calls it, but is then DISCARDed in the linkerscript, thus the linker will fail with an error message.
|
FYI some numbers of LTO erformance. I started working on LTO enabling while working on a bootloader application. At first it saved me ~400 bytes of Flash, and it was nice. I commented out the function and compared the flash size with and without LTO. The LTO one had ~20% more, so I decided not to use it in the end (I guess, I should have gained some performance boost, but that is not really important for the bootloader). For the bigger project I get 92,5 kB without LTO and 97 kB with LTO. Have not measured the performance yet. So, after all I would not recommend to have LTO enabled by default in the Release build. Maybe, would be nice to have it as an additional target (Debug - Release - ReleaseLto) |
Uff, that's not great. That must have pulled a lot of code in there. I found what I was thinking of: LTO with custom linkerscripts is still not fully supported and does weird things. I wish there was an open-source linker specially for embedded. There are already commercial linkers, but they are expensive. |
|
When exploding to 59kb, the code definetely used heap allocation as the linker was looking for sbrk_r again.
If you want, I can check section allocations on Monday to check the data placement
С уважением, / Best regards
Плужников Сергей / Sergey Pluzhnikov
…________________________________
From: Niklas Hauser ***@***.***>
Sent: Saturday, November 19, 2022 5:33:04 PM
To: modm-io/modm ***@***.***>
Cc: ser-plu ***@***.***>; Author ***@***.***>
Subject: Re: [modm-io/modm] Ref. #926. Fixes for LTO build. (PR #928)
the binary size exploded from 5 to 59 kB
Uff, that's not great. That must have pulled a lot of code in there.
I found what I was thinking of: LTO with custom linkerscripts is still not fully supported and does weird things.
https://twitter.com/modm_embedded/status/1366870337820983296
That's from 2020 though, but I haven't been able to find any progress of this work since then.
I wish there was an open-source linker specially for embedded. There are already commercial linkers, but they are expensive.
—
Reply to this email directly, view it on GitHub<#928 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3U7W6V2SFDWOAUXCC3ENXTWJD6MBANCNFSM6AAAAAAR2UXHP4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Resolves issues, appearing during LTO build: