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

[Andrew Haley]

On Fri, 29 Sep 2023 18:48:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> If this is a native frame the current FP would point to the current's frame lowest address. The value stored there would be the sender's FP.
>> 
>> Yes to both of those.
>> 
>>> If the sender is also a native frame, then that value would just point to the lowest address of that frame.
>> 
>> Maybe. I think that's the way GCC works, but not the ABI. All the ABI guarantees is that the frame pointers form a chain. And I don't know that GCC always does it this way, e.g. with variable-size arrays. At least this needs a comment.
>
> Ah, is your concern about setting the right _unextended_sp/_sp value when the caller is also a native frame? If that's the case then yes we would need to know where the frame records are stored to know what to do. I guess the assumption was already that they were stored at the lowest address and that's why we pass fr->link() for the sp when constructing the sender frame. But in any case that sp value is not used to get the sender so even if the value is not correct we won't crash. If that was your concern I can add a comment for that.

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. 

So why is MacOS different?

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

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