Open kito-cheng opened 4 months ago
cc. @cmuellner @apazos @topperc @asb @aswaterman
Thanks @kito-cheng for posting this issue.
A few remarks about the clipped figures from the PDF file posted in the discussion:
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
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.
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:
And proposed stack layout and frame pointer scheme: