test: kernel: Exclude broken LTO builds

[rettichschnidi]

This disables the LTO builds for platforms which are affected by build errors.

While not a solution for the underlying issue, those changes will allow unrelated PRs with changes in the kernel code to pass CI and get merged.

Hint: #70426 tries to resolve the same issue

[danieldegrasse]

If we want to use this solution, we should disable builds based on if CONFIG_CODE_RELOCATION is selected- this is the actual underlying issue that is affecting these platforms, and could affect other ones as well

[rettichschnidi]

If we want to use this solution, we should disable builds based on if CONFIG_CODE_RELOCATION is selected- this is the actual underlying issue that is affecting these platforms, and could affect other ones as well

Just updated the PR. I guess you meant CONFIG_CODE_DATA_RELOCATION.

[tejlmand]

I think it's better to prevent LTO with Code relocation enabled.
At least until it has been ensured that those two features generally works together.

Thus instead of the changes proposed in this PR, then make an extra dependency here:

zephyr/Kconfig.zephyr

Lines 430 to 432 in 1408d1e

	config LTO
	bool "Link Time Optimization [EXPERIMENTAL]"
	depends on (!(GEN_ISR_TABLES || GEN_IRQ_VECTOR_TABLE) || ISR_TABLES_LOCAL_DECLARATION) && !NATIVE_LIBRARY

like:

depends on (!(GEN_ISR_TABLES || GEN_IRQ_VECTOR_TABLE) || ISR_TABLES_LOCAL_DECLARATION) && !NATIVE_LIBRARY && !CODE_DATA_RELOCATION

@rakons have you done any verification related to LTO and the code relocation feature ?

[rettichschnidi]

I think it's better to prevent LTO with Code relocation enabled.
At least until it has been ensured that those two features generally works together.

I created a (draft) PR with this idea: #70426

While it also resolves (works around) my issue of no longer being able to pass CI with unrelated code changes, I am not a fan of it as it produce a new warning:

warning: LTO (defined at Kconfig.zephyr:430) was assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies: (!CODE_DATA_RELOCATION) (=n)

[rakons]

I had stated already in some issue here that I am not expecting LTO work as expected with code relocation.

---

Ok - found it: #69730 (comment)
Sorry - I did not have a time to discover it. I also do not think that we are using it at Nordic - so it would be hard to find any board to test the issue. What do I need?

[danieldegrasse]

I think it's better to prevent LTO with Code relocation enabled.
At least until it has been ensured that those two features generally works together.

@tejlmand Do you think it would be possible to exclude the files relocated with code relocation using the prohibit_lto compiler property, like it is done here?: https://github.com/zephyrproject-rtos/zephyr/blob/main/CMakeLists.txt#L815

I am not sure if we can, since the code relocation feature uses generator expressions heavily. I tried to implement this to fix #69730 but did not get very far.

[tejlmand]

I think it's better to prevent LTO with Code relocation enabled.
At least until it has been ensured that those two features generally works together.

@tejlmand Do you think it would be possible to exclude the files relocated with code relocation using the prohibit_lto compiler property, like it is done here?: https://github.com/zephyrproject-rtos/zephyr/blob/main/CMakeLists.txt#L815

I am not sure if we can, since the code relocation feature uses generator expressions heavily. I tried to implement this to fix #69730 but did not get very far.

I believe it should be possible.
I'm occupied with HWMv2 atm and won't have time to look into the details.

Implementing it should not take long but testing / verifying that things indeed work as expected is where I believe most time will need to be spend.

[tejlmand]

@rettichschnidi I believe a combination of this PR (which filters out tests that enables data relocation) with the proposal in #70426 to avoid enabling LTO together with relocation will be the optimal solution to this problem.