RFR: 8277948: AArch64: Print the correct native stack if -XX:+PreserveFramePointer when crash

[Denghui Dong]

On Tue, 7 Dec 2021 15:37:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> > Thank you for this. I'll have a look.
>>> > Stack unwinding on AArch64 C/C++ uses call frame information, which is in a separate section in the binary file. This allows the stack to be fully traced, even if there is no frame pointer. There is a library, libunwind, which does this. But that won't work with Java, which has its own way to do it
>>> > It would be nice to get -XX:+PreserveFramePointer working correctly.
>>> 
>>> Thanks for the response.
>>> 
>>> I also noticed that a java method will reserve 2 words when this method makes a vm leaf call:
>> 
>> It's not reserving anything, it's saving the PC for the stack unwinder.
>> 
>>> ```
>>> aarch64.ad
>>> 
>>> aarch64_enc_java_to_runtime
>>> 
>>>       Label retaddr;
>>>       __ adr(rscratch2, retaddr);
>>>       __ lea(rscratch1, RuntimeAddress(entry));
>>>       // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
>>>       __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>>>       __ blr(rscratch1);
>>>       __ bind(retaddr);
>>>       __ add(sp, sp, 2 * wordSize);
>>> ```
>> 
>> I wrote it. If you look at `JavaFrameAnchor::capture_last_Java_pc()` you'll see
>> it being used.
>> 
>>> ```
>>> MacroAssembler::call_VM_leaf_base
>>> 
>>> 
>>>   stp(rscratch1, rmethod, Address(pre(sp, -2 * wordSize)));
>>> 
>>>   mov(rscratch1, entry_point);
>>>   blr(rscratch1);
>>>   if (retaddr)
>>>     bind(*retaddr);
>>> 
>>>   ldp(rscratch1, rmethod, Address(post(sp, 2 * wordSize)));
>>> ```
>>> 
>>> I haven't figured out the specific purpose of this operation, but I think it will make the logic of stack walking more complicated.
>> 
>> All this is doing is saving `rmethod` (which is in a call-clobbered register) around a VM call. `retaddr` is saved for OOP maps.
>
>> Hi @theRealAph , Sorry to disturb you again, I have one more question.
>> 
>> Under the current implementation, if the number of parameters of callee exceeds the number of parameter registers, the parameters on the stack cannot be read correctly, right?
>> 
>> ```
>> aarch64.ad
>> 
>> aarch64_enc_java_to_runtime
>> 
>>       Label retaddr;
>>       __ adr(rscratch2, retaddr);
>>       __ lea(rscratch1, RuntimeAddress(entry));
>>       // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
>>       __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>>       __ blr(rscratch1);
>>       __ bind(retaddr);
>>       __ add(sp, sp, 2 * wordSize);
>> ```
> 
> I think that's right, but there are no runtime calls with so many arguments, and I don't think there are likely to be. We should perhaps assert that.

Hi @theRealAph ,

Do you have any comments on this patch?

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

PR: https://git.openjdk.java.net/jdk/pull/6597