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

[Denghui Dong]

On Mon, 6 Dec 2021 13:45:47 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:
>> 
>> 
>> 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);
>> 
>> 
>> 
>> 
>> 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.
>
>> > 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);

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

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