Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New ABI for stack layout and frame pointer scheme #437

Open
kito-cheng opened this issue May 10, 2024 · 4 comments
Open

New ABI for stack layout and frame pointer scheme #437

kito-cheng opened this issue May 10, 2024 · 4 comments

Comments

@kito-cheng
Copy link
Collaborator

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
Copy link
Collaborator Author

@apazos
Copy link

apazos commented May 13, 2024

Thanks @kito-cheng for posting this issue.

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

  • The current ABI states that “the frame pointer register will point to the Canonical Frame Address or CFA, which is the stack pointer value on entry to the current procedure.”
  • In the alternative ABI "the frame pointer points to the saved return address in the CM.PUSH/CM.POP stack frame".
  • If we opt for an alternative ABI for no-omit-frame-pointer + Zcmp and rely on the linker to do compatibility checks for ABI mix, I think we would need an ELF attribute that indicates that the frame pointer is enabled so the linker can implement the proper checks.

@james-ball-qualcomm
Copy link

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
Copy link
Collaborator

sorear commented May 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants