Codify Save/Restore Frame Layout #70
Conversation
|
@kito-cheng I know you did the GCC implementation, hopefully you feel this wording is good enough to allow some flexibility in implementation, while still ensuring compilers can emit the right CFI information? |
lenary
force-pushed
the
pr/save-restore-layout
branch
from
790e21a to
35aff36
Compare
| address register `ra` is always included in the registers saved and restored. | ||
| `<N>` is a value between 0 and 12 and corresponds to the number of registers | ||
| between `s0` and `s11` that are saved/restored. When using the `ILP32E` ABI, | ||
| `<N>` can be at most 2, as `s3` to `s12` are not CSRs. |
There was a problem hiding this comment.
Could you expand CSRs? I know it's the term used in LLVM for callee saved regs, but it might be ambiguous in the RISC-V land since Control and Status Register also called CSR.
(And caller-saved reg can also abbreviated as CSR as well in theory...)
src/toolchain-conventions.adoc
Outdated
|
|
||
| In all the save restore routines, across all ABIs, `ra` is stored adjacent to | ||
| the incoming stack pointer (highest address), then the CSRs in register order | ||
| from `s0` to `s11`. This follows the Frame Pointer Convention, whether or not a |
There was a problem hiding this comment.
| from `s0` to `s11`. This follows the Frame Pointer Convention, whether or not a | |
| from `s0` to `s11`. This follows the [Frame Pointer Convention](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc#frame-pointer-convention), whether or not a |
| While the implementation of the save restore routines are in the library, it is | ||
| the compiler's responsibility to emit the unwind information (CFI) for the | ||
| registers that are saved and restored by these routines, so the compilers and | ||
| the libraries must agree on the stack layouts used by these routines. |
There was a problem hiding this comment.
Some random thing come to my mind:
GCC always use libgcc since it's not provide a command line option to let user use compiler-rt, but LLVM offer option to let user using either libgcc or compiler-rt?
However I guess it's may not the problem on the spec side, it's implementation side issue: either 1) align libgcc and compiler-rt or 2) LLVM will gen the CFI according the runtime library preference if libgcc and compiler-rt has different layout.
There was a problem hiding this comment.
For most of the ABIs, we are already at 1 as far as I understand, and I think that is the way to go, on the basis that libgcc can either be a shared or a static link (I'm not sure if compiler-rt is the same).
I think the only place where anyone differs from the description is the ilp32e ABI, which is still unstable everywhere, so this change can be made to the libraries as long as it is noted (hence my PR to compiler-rt).
I would really prefer not to have to teach LLVM to emit two different CFI directive sets depending on the library chosen.
I recall in the investigations that ilp32e CFI information from GCC is not correct anyway, so needs re-checking? Maybe I'm wrong about that or it's been fixed since I noticed.
These layouts need to be compatible between what the compiler expects when emitting CFI information, and what the library actually implements, so we write a bit more detail about how these should work to ensure that compatibility. Fixes riscv-non-isa#35 Signed-off-by: Sam Elliott <[email protected]>
lenary
force-pushed
the
pr/save-restore-layout
branch
from
35aff36 to
07462b9
Compare
These layouts need to be compatible between what the compiler expects when emitting CFI information, and what the library actually implements, so we write a bit more detail about how these should work to ensure that compatibility.
Fixes #35