Failed to unwind stack on RISCV-64

[shkim-rc]

Hello. I've found a bug on my RISCV-64 environment.
I used GCC to build perfetto packages and my target environment uses GNU's libraries such as glibc.

Before copying the stack, the client hooking library tries to get the stack address by using __builtin_frame_address().
In ARM32 and AARCH64, this builtin function works fine so stack unwinding is completed successfully.
But, in RISCV-64, it makes an error due to the difference between calling conventions of architectures.

See the following assembly codes:

  RISC-V64:
    0x3f8639ad62:    add    sp,sp,-544
    0x3f8639ad66:    sd    ra,536(sp)
    0x3f8639ad6a:    sd    s0,528(sp)
    0x3f8639ad6e:    add    s0,sp,544

  AARCH64:
    0x7f79bd36b0:    sub    sp, sp, #0x210
    0x7f79bd36b4:    stp    x29, x30, [sp]
    0x7f79bd36b8:    mov    x29, sp

I've got above codes by using GCC-14 (for RISC-V64) and GCC-9 (for AARCH64).
Both codes are first few lines of RecordMalloc. (in src/profiling/memory/client.cc)
In RISCV-V64, an s0 register (used for the frame pointer) has a caller's stack pointer value while an x29 register (used for the frame pointer in AARCH64) has a modified stack pointer value. So, stack unwinding in RISC-V64 is failed because it tries to get the first return address (stored in sp + 8).

So, I suggest that use the value in the stack pointer register instead of using the frame pointer.
In the process of RecordMalloc, the function anyway reads the registers. So, we can get the stack pointer value easily.
If the compiler provides __builtin_stack_address(), we can use it.

[LalitMaganti]

Thanks for the report. Any RISC-V code in Perfetto is basically totally untested so it's unsurprising that bugs like this exist. We also don't have any capacity to support it given we have no Ci running tests there.

So patches welcome following the guide at https://perfetto.dev/docs/contributing/getting-started but not something we can fix on our side otherwise.

[shkim-rc]

Thanks for the report. Any RISC-V code in Perfetto is basically totally untested so it's unsurprising that bugs like this exist. We also don't have any capacity to support it given we have no Ci running tests there.

So patches welcome following the guide at https://perfetto.dev/docs/contributing/getting-started but not something we can fix on our side otherwise.

Thank you for your reply!
Actually, I uploaded a patch related with this issue. Please, refer this link

[LalitMaganti]

Great thanks! Let's continue the conversation there.