RFR: 8316309: AArch64: VMError::print_native_stack() crashes on Java native method frame [v2]

[Patricio Chilano Mateo]

On Mon, 2 Oct 2023 16:23:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

> OK, I think I get it now. The sender_sp may or may not really be the actual SP in a native frame (although with current GCC it is) but we do know that there is a chain of {frame pointer, PC} pairs. If we find a PC that is in a code buffer somewhere in that chain, we can find the size of the corresponding Java stack frame, and by subtraction the "real" SP of that Java frame.
>
Exactly.

> So why is MacOS different?
>
Clang saves the frame records at the bottom of the frame (highest address), so using fr->sender_sp() works fine there. I can change it to have the same fix as gcc if we don't want to rely on that assumption. The only reason why I went with that simpler fix is that I think knowing that the sender sp is always two words above the current rfp would allow to walk the stack in some cases whereas with the other fix we would crash. Like if a frame passes the os::is_first_C_frame() check but fr->link() is not really the sender's rfp, doing rfp + 2 would still give a valid sender sp, whereas with the other calculation it would set a wrong value. But maybe that's very unlikely. I still added a new test that will fail if the location of the frame records change. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15972#discussion_r1343032146