[9] RFR(S): 8080650: enable stubs to use frame pointers correctly
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Oct 13 12:24:49 UTC 2015
This seems right.
Did you run with -XX:-UseStackBanging? Run at least jtreg tests.
Thanks
Vladimir
On 10/13/15 6:30 PM, Zoltán Majó wrote:
> 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