[9] RFR(S): 8080650: enable stubs to use frame pointers correctly
Zoltán Majó
zoltan.majo at oracle.com
Tue Oct 13 10:30:32 UTC 2015
Hi Vladimir,
On 10/12/2015 04:25 PM, Vladimir Kozlov wrote:
> The code which does not do stack banging seems incorrect - RSP is
> modified before it is saved in RBP:
>
> subptr_imm32(rsp, framesize);
you are right and thank you for catching the mistake!
Here is the updated webrev:
http://cr.openjdk.java.net/~zmajo/8080650/webrev.01/
I re-executed all JPRT tests (testset hotspot), all tests pass.
Thank you and best regards,
Zoltan
>
> Thanks,
> Vladimir
>
> On 10/12/15 8:42 PM, Zoltán Majó wrote:
>> Hi,
>>
>>
>> please review the following patch for JDK-8080650.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080650
>>
>>
>> Problem: The following stack frame layout allows external tools (e.g.,
>> Linux perf or Solaris pstack) to determine the call chain currently on
>> the stack:
>>
>> ...
>> ======================== ^
>> 0x108 | return address | | caller's frame
>> ======================== ====================
>> 0x100 | RBP of caller | | callee's frame
>> ======================== v
>> ...
>>
>> The example above assumes a 64-bit architecture, the addresses 0x108 and
>> 0x100 are randomly chosen.
>>
>> For stack tracing to work, RBP must have the value 0x100 while execution
>> is in the method "callee". However, when HotSpot generates code that
>> does not need stack banging (e.g., stubs), RBP is assigned anincorrect
>> value. For stubs, RBP is 8 bytes off the incorrect value (e.g., RBP
>> contains the value 0x108 instead of 0x100 for the above example).
>>
>>
>> Solution: Change MacroAssembler::verified_entry() to set up RBP
>> correctly when generating stub code. Setting up RBP is now done the same
>> way as it is done for compiled code (i.e., when stack banging is
>> needed).
>>
>> Webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.00/
>>
>> Testing:
>> - JPRT (testset hotspot), all tests pass;
>> - locally executed all hotspot JTREG tests and all JTREG tests in
>> jdk/test/java/lang/invoke, all tests pass that pass with an
>> unmodified VM.
>>
>>
>> Many thanks to Hongxi Sy for reporting this problem.
>>
>> Thank you and best regards,
>>
>>
>> Zoltan
>>
More information about the hotspot-compiler-dev
mailing list