tests: lto: mimxrt1170_evk/mimxrt1176/cm7 : tests/kernel/common/lto hangs

[hakehuang]

Describe the bug mimxrt1170_evk/mimxrt1176/cm7 : tests/kernel/common/lto hangs no console output

Please also mention any information which could help others to understand the problem you're facing:

• What target platform are you using?
• mimxrt1170_evk/mimxrt1176/cm7 or mimxrt1170_evk_cm7
• What have you tried to diagnose or workaround this issue?
• disable LTO

• Is this a regression? If yes, have you been able to "git bisect" it to a specific commit?

  118f1592ff5d04cdcb35d779c3e93575cfad71ae is the first bad commit
  commit 118f1592ff5d04cdcb35d779c3e93575cfad71ae
  Author: Radoslaw Koppel <radoslaw.koppel@nordicsemi.no>
  Date:   Tue Feb 27 13:17:37 2024 +0100
  
  buildsystem: Enable LTO also for the application
  
  It turns out that currently LTO is enabled only for the kernel.
  This commit updates it to enable it for the whole application
  and adds additional LTO exclusions required for the standard
  C libraries to build and link properly.
  
  Signed-off-by: Radosław Koppel <radoslaw.koppel@nordicsemi.no>
  
  CMakeLists.txt                   | 2 +-
  lib/libc/newlib/CMakeLists.txt   | 3 +++
  lib/libc/picolibc/CMakeLists.txt | 3 +++
  3 files changed, 7 insertions(+), 1 deletion(-)

To Reproduce Steps to reproduce the behavior: west build -b mimxrt1170_evk_cm7 tests/kernel/common/ -p always -- -DCONFIG_TEST_USERSPACE=n -DCONFIG_ISR_TABLES_LOCAL_DECLARATION=y -DCONFIG_LTO=y or west build -b mimxrt1170_evk/mimxrt1176/cm7 tests/kernel/common/ -p always -- -DCONFIG_TEST_USERSPACE=n -DCONFIG_ISR_TABLES_LOCAL_DECLARATION=y -DCONFIG_LTO=y

Expected behavior test pass

Impact LTO feature

Logs and console output

no log output at all, gdb fould below status, looks code goes to the reserved area.

#0  0x00223104 in ?? ()
#1  0x002015f2 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info register
r0             0x40cac0b0          1087029424
r1             0xa000000           167772160
r2             0x80000000          2147483648
r3             0xf000              61440
r4             0xe000ed00          3758157056
r5             0x22946d            2266221
r6             0x1640cd            1458381
r7             0x207dc8            2129352
r8             0x2024ae80          539274880
r9             0x2024ae84          539274884
r10            0x211c0c            2169868
r11            0xf0                240
r12            0x0                 0
sp             0x20241d98          0x20241d98
lr             0x2015f3            0x2015f3
pc             0x223104            0x223104
xpsr           0x1000000           16777216
fpscr          0x0                 0
msp            0x20241d98          539237784
psp            0x0                 0
control        0x0                 0
faultmask      0x0                 0
basepri        0x0                 0
primask        0x1                 1
cycles         0x870c04            8850436
fpccr          0xc0000000          3221225472
fpcar          0xfffffff8          4294967288
fpdscr         0x0                 0
mvfr0          0x10110221          269550113
mvfr1          0x12000011          301989905

Environment (please complete the following information):

• OS: (e.g. Linux, MacOS, Windows)
• Toolchain (e.g Zephyr SDK, ...)
• Commit SHA or Version used: v3.6.0-915-gf1186d29d07

[hakehuang]

tests/kernel/interrupt/arch.shared_interrupt.lto has the same problem

[aescolar]

CC @rkel

[decsny]

@aescolar why is this marked as medium if LTO is still experimental?

[aescolar]

@decsny in the release team we do an initial triage which sometimes can be a bit off. As assignee you are welcome to change the priority, correct labels and reassign. If you can justify it in a comment even better.

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.