On Mon, 28 Oct 2024 17:31:45 GMT, Patricio Chilano Mateo <pchilanom...@openjdk.org> wrote:
>> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188: >> >>> 186: // Avoid using a leave instruction when this frame may >>> 187: // have been frozen, since the current value of rfp >>> 188: // restored from the stub would be invalid. We still >> >> It sounds like freeze/thaw isn't preserving FP, even though it is a >> callee-saved register according to the ABI. If the stubs tried to modify FP >> (or any other callee-saved register) and use that value after the native >> call, wouldn't that be a problem? >> Do we actually need FP set by the enter() prologue for stubs? If we can >> walk compiled frames based on SP and frame size, it seems like we should be >> able to do the same for stubs. We could consider making stub >> prologue/epilogue look the same as compiled frames, then this FP issue goes >> away. > >>It sounds like freeze/thaw isn't preserving FP, even though it is a >>callee-saved register according to the ABI. If the stubs tried to modify FP >>(or any other callee-saved register) and use that value after the native >>call, wouldn't that be a problem? >> > Yes, that would be a problem. We can't use callee saved registers in the stub > after the call. I guess we could add some debug code that trashes all those > registers right when we come back from the call. Or maybe just adding a > comment there is enough. > Do we actually need FP set by the enter() prologue for stubs? If we can walk > compiled frames based on SP and frame size, it seems like we should be able > to do the same for stubs. We could consider making stub prologue/epilogue > look the same as compiled frames, then this FP issue goes away. > I think we need it for the pending exception case. I see we use rfp to get the exception pc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819474263
