riscv-non-isa / riscv-elf-psabi-doc

A RISC-V ELF psABI Document
https://jira.riscv.org/browse/RVG-4
Creative Commons Attribution 4.0 International
691 stars 163 forks source link

New ABI for stack layout and frame pointer scheme #437

Open kito-cheng opened 4 months ago

kito-cheng commented 4 months ago

This is a placeholder for discuss the issue around Zcmp frame pointer issue.

The original thread from RVI mailing list https://lists.riscv.org/g/tech-psabi/message/154

Link for history:

Slide from Qcom: Qualcomm RISC-V Push&Pop&FP Proposal.pdf

Current stack layout and frame pointer scheme: Selection_191

And proposed stack layout and frame pointer scheme:

stackFrames-CM

kito-cheng commented 4 months ago

cc. @cmuellner @apazos @topperc @asb @aswaterman

apazos commented 4 months ago

Thanks @kito-cheng for posting this issue.

A few remarks about the clipped figures from the PDF file posted in the discussion:

james-ball-qualcomm commented 4 months ago

The previously attached PDF of the slides is out of date. Please use the latest version at: https://docs.google.com/presentation/d/1Qk-pNJ5svY8trYW3Smk073ok9pcEJFc5hsx4rbOoj5M

sorear commented 4 months ago

I would suggest to point the fp within each stack frame one word after the saved s0 value, so that -XLEN/8(fp) is the saved fp and -2*XLEN/8(fp) is the saved ra. This allows stack trace code to support both conventions (mixed, even) in the common case that stack bounds are known:

[unwind psuedocode]
while ((fp - stack_base) < stack_size) {
    if ((fp[-1] - stack_base) < stack_size) {
        ra = fp[-2]; fp = fp[-1]; /* Zcmp optimized convention */
    } else {
        ra = fp[-1]; fp = fp[-2]; /* ABI 1.1 convention */
    }
    print(ra);
}

This works because valid stack addresses are disjoint from valid instruction addresses.

A preprocessor define will be needed to communicate the use of the new ABI to unwinders when there is not enough information at runtime to distinguish stack and instruction addresses. It might be worth defining an ELF attribute for future-proofing, although mixing code using both frame pointer conventions may not be an error.