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

[Patricio Chilano Mateo]

On Fri, 29 Sep 2023 17:30:58 GMT, Andrew Haley <aph 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. If the sender is also a native frame, then that value would just point to the lowest address of that frame. If the sender is a frame associated with some CodeBlob and we know its size then the sender's FP would point two words below the highest address of that frame (unless the sender's FP value is wrong but then _unextended_sp would be wrong anyways if we set it to the sender's FP as the old code) and we can calculate the actual _unextended_sp so that when getting the sender of that frame we don't crash.
>
>> 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.

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

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