ARC wrong .debug_frame

[userid0x0]

Describe the bug
With optimizationlevel -Os the ARC GCC 10.3.0 of the Zephyr SDK generates .debug_frame information with wrong polarity. I observed the following behavior. With "-Os" the instruction enter_s is used. For these instructions the .debug_frame creates information like

RET:BLINK CFA:SP+0x8 R13:*CFA+0x8 R14:*CFA+0x4

(increment the SP by 0x8=CFA, in order to find the stacked R13 increment the CFA again by 0x8)
but it should be

RET:BLINK CFA:SP+0x8 R13:*CFA-0x8 R14:*CFA-0x4

as the stacked data should be within the CFA not outside. When the compiler generates e.g. push_s instructions the .debug_frame information is correct.
The behavior is detected using a TRACE32 debugger and confirmed by objdump. For TRACE32 the wrong .debug_frame prevents an successful callstack unwind.

Workarounds detected: use lower optimization levels -O0/-O1/-Og/-O2

To Reproduce
Steps to reproduce the behavior:

1. west build -b qemu_arc_em --pristine auto samples/synchronization

In order to inspect the file use e.g. objdump

1. /arc-zephyr-elf-objdump --dwarf=frames build/zephyr/zephyr.elf

Or use TRACE32 for ARC Simulator e.g. R2022.02

1. SYStem.CPU ARC-EM
2. SYStem.Up
3. Data.LOAD /build/zephyr/zephyr.elf
4. sYmbol.List.FRAME

Impact
Prevents debugging.

Environment (please complete the following information):

• OS: Linux
• Toolchain: Zephyr SDK 0.14.2
• Zephyr 3.1.0

[userid0x0]

I cross checked with Zephyr SDK 0.15.0-beta2 - same behavior.

[abrodkin]

@claziss could you please comment on this one?

[userid0x0]

I created a simple testcase using the same GCC flags as Zephyr uses
https://github.com/userid0x0/arc-debug_frame
I included the objdumps as reference. Using -O2 the CFA references are all negative

00000060 00000038 00000000 FDE cie=00000000 pc=00000278..00000348
DW_CFA_advance_loc: 2 to 0000027a
DW_CFA_def_cfa_offset: 4
DW_CFA_offset: r31 at cfa-4
DW_CFA_advance_loc: 4 to 0000027e
DW_CFA_def_cfa_offset: 8
DW_CFA_offset: r17 at cfa-8
...

using -Os the CFA references are positive if the compiler uses enter_s. The resulting adresses are outside of the frame

00000070 00000038 00000000 FDE cie=00000000 pc=000002c0..00000350
DW_CFA_advance_loc: 2 to 000002c2
DW_CFA_def_cfa_offset: 32
DW_CFA_offset_extended_sf: r31 at cfa+32
DW_CFA_offset_extended_sf: r13 at cfa+28
DW_CFA_offset_extended_sf: r14 at cfa+24
DW_CFA_offset_extended_sf: r15 at cfa+20
DW_CFA_offset_extended_sf: r16 at cfa+16
DW_CFA_offset_extended_sf: r17 at cfa+12
DW_CFA_offset_extended_sf: r18 at cfa+8
DW_CFA_offset_extended_sf: r19 at cfa+4

[claziss]

The dwarf info associated to enter_s instruction is wrong. I'll fix it asap.

[userid0x0]

@claziss Is there a range of affected GCC versions available? We can add a workaround limited for these versions.

[claziss]

@userid0x0 it is a day zero bug. An work around is not to use size optimized option (i.e. -Os), maybe using -O2 option for the time being.