riscv stack pointer offset · cranelift

Stream: cranelift

Topic: riscv stack pointer offset

Jonas Kruckenberg (Feb 23 2025 at 14:01):

Okay so quick sanity check, it appears that (on riscv anyways) the frame pointer points to a different field in

afaik under LLVM:

----  frame ---- <- fp points here
ra,
fp,
...
---- frame ----

while under cranelift its

----  frame ----
ra,
fp,   <- fp points here
...
---- frame ----

is that correct? or am I missing something :thinking:

Alex Crichton (Feb 23 2025 at 18:19):

The cranelift side is an accurate depiction of what we do today yeah, and I believe that fell out of "well by default might as well match x64". If LLVM uses a different frame layout though we should probably update to match that

Jonas Kruckenberg (Feb 23 2025 at 19:07):

its very hard to find out what llvm is actually doing, but all stack walking implementations work that way yeah

Jonas Kruckenberg (Feb 23 2025 at 19:08):

Alex Crichton said:

If LLVM uses a different frame layout though we should probably update to match that

i mean its not too big of a deal, but it would be great if i could just use the same unwinder for all code of course yeah

Amanieu (Feb 23 2025 at 19:54):

The convention on RISC-V is to have the FP point above the frame record. The Linux perf unwinder relies on this.

Alex Crichton (Feb 23 2025 at 22:35):

@Jonas Kruckenberg mind filing an issue on wasmtime for this?

Jonas Kruckenberg (Feb 24 2025 at 10:46):

https://github.com/bytecodealliance/wasmtime/issues/10281

Cranelift: RISCV frame pointer position differs from LLVM · Issue #10281 · bytecodealliance/wasmtime

Cranelift on RISCV (when frame pointers are enabled) generated code where the fp register always points to the next frame pointer like so: ---- frame ---- ra, fp, <- fp points here ... ---- frame -...

Last updated: Feb 27 2025 at 22:03 UTC