kernel: Add Kconfig option to disable LTO for kernel sources #99124
Conversation
zephyrbot
requested review from
Chenhongren,
Dino-Li,
RuibinChang,
fabiobaltieri and
keith-zephyr
| # Append the injected code to the end of the file | ||
| file(APPEND ${KERNEL_CMAKE} "${INJECT_CODE}") |
There was a problem hiding this comment.
uh, why is this needed? The whole append/remove thing feels a bit hacky to be honest, hope we can find a different solution, you just need the -fno-lto -g in the build command line for the files above right?
There was a problem hiding this comment.
The reason is that setting -fno-lto elsewhere (e.g. board-level CMake) didn’t work likely because of build order issues. Kernel sources were still built with LTO, so I had to apply it directly here to make sure those files compile without LTO and can reside in RAM.
There was a problem hiding this comment.
ok so this is basically touching the source file to somehow convince cmake to build it again with the new flag?
There was a problem hiding this comment.
Yes, that's correct, it temporarily modifies the kernel CMake file to ensure those specific sources are rebuilt with -fno-lto. After the build configuration is complete, the injected changes are automatically cleaned up to restore the original file state.
There was a problem hiding this comment.
Got it. I don't really think it's a good idea to try and modify non generated files from the build script, @tejlmand do you have a better approach to suggest?
Would we not be able to get away with adding a Kconfig flag and the options in the kernel CMakeLists.txt file directly? If this SoC has a scenario where having a kernel specific option to selectively not do LTO it may be handy for other devices too.
There was a problem hiding this comment.
Instead of modifying the kernel's CMake file, what about creating a separate CMake file that defines the no-LTO and other desired properties?
You could have the kernel CMake file do a conditional include based on a CONFIG option being set.
There was a problem hiding this comment.
Thanks @fabiobaltieri and @keith-zephyr for the helpful suggestions.
I’ve updated the implementation accordingly. It now adds a Kconfig option to control the behavior, and the logic is handled inside kernel/CMakeLists.txt without modifying it from external scripts. Additionally, I’ve added a separate kernel_no_lto.cmake file to define the no-LTO settings.
GTLin08
force-pushed
the
it8xxx2_kernel_in_ram_lto
branch
from
d69e872 to
e660d0d
Compare
zephyrbot
requested review from
TaiJuWu,
andyross,
ceolin,
cfriedt,
dcpleung,
nashif,
npitre and
peter-mitsis
GTLin08
changed the title
Some SoCs require kernel code to be placed in RAM, which makes link-time optimization (LTO) unsuitable for these files. Disabling LTO allows the affected code to be linked as separate objects and placed in specific memory regions. Running kernel code from RAM can improve execution performance, especially for timing-critical routines or context switch paths. Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
Select KERNEL_NO_LTO only when LTO is enabled. This ensures proper handling when kernel code is placed in RAM. Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
GTLin08
force-pushed
the
it8xxx2_kernel_in_ram_lto
branch
from
e660d0d to
123ab0b
Compare
|
| NOT src MATCHES "errno\\.c$" AND | ||
| NOT src MATCHES "fatal\\.c$" AND | ||
| NOT src MATCHES "init\\.c$") |
There was a problem hiding this comment.
Should these files be added to the LTO_ALLOWLIST as the default settings?
8 participants
Some SoCs require kernel code to be placed in RAM, which makes link-time optimization (LTO) unsuitable for these files.
Disabling LTO allows the affected code to be linked as separate objects and placed in specific memory regions.
Running kernel code from RAM can improve execution performance, especially for timing-critical routines or context switch paths.
Another commit is to enable
KERNEL_NO_LTOwhenSOC_IT8XXX2_KERNEL_IN_RAMandLTOare enabled on the IT8XXX2 chip.