v3.7-branch: arch: riscv: stacktrace: trace is incomplete when unwinding from function without callee

[ycsin]

Describe the bug
When unwinding from a function without callee, such as sys_clock_cycle_get_32():

00000000800062c0 <sys_clock_cycle_get_32>:
    800062c0:	1141                	addi	sp,sp,-16
    800062c2:	e422                	sd	s0,8(sp)    <--- fp is stored here, ra not stored
    800062c4:	0800                	addi	s0,sp,16
    800062c6:	0200c7b7          	lui	a5,0x200c
    800062ca:	ff87b503          	ld	a0,-8(a5) # 200bff8 <CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC+0x1682978>
    800062ce:	6422                	ld	s0,8(sp)
    800062d0:	2501                	sext.w	a0,a0
    800062d2:	0141                	addi	sp,sp,16
    800062d4:	8082                	ret

The fp is stored at 8(sp) which is where the ra is expected to stored for function with callee, i.e. sys_clock_driver_init():

00000000800061aa <sys_clock_driver_init>:
    800061aa:	1141                	addi	sp,sp,-16
    800061ac:	e022                	sd	s0,0(sp)    <--- fp is stored here
    800061ae:	e406                	sd	ra,8(sp)    <--- ra is stored here for function with callee
    800061b0:	0800                	addi	s0,sp,16
    800061b2:	4601                	li	a2,0
    800061b4:	4581                	li	a1,0
    800061b6:	451d                	li	a0,7
    800061b8:	fa6fa0ef          	jal	ra,8000095e <z_riscv_irq_priority_set>
    ...

or, z_impl_k_busy_wait():

00000000800062d6 <z_impl_k_busy_wait>:
    800062d6:	c91d                	beqz	a0,8000630c <z_impl_k_busy_wait+0x36>
    800062d8:	1101                	addi	sp,sp,-32
    800062da:	e822                	sd	s0,16(sp)    <--- fp is stored here
    800062dc:	e426                	sd	s1,8(sp)
    800062de:	e04a                	sd	s2,0(sp)
    800062e0:	ec06                	sd	ra,24(sp)    <--- ra is stored here

This resulted in the second function from function without callee to be missing

To Reproduce

1. Checkout https://github.com/ycsin/zephyr/tree/pr/arch_stack_walk_perf
2. Dump and visualize traces

Expected behavior
Traces should be complete regardless from where the unwinding starts

Impact
Imcomplete stack traces.

[mmahadevan108]

@ycsin Can this issue be closed

[ycsin]

@ycsin Can this issue be closed

Not yet, issue is required to backport PRs to v3.7, I've updated the title to reflect that