[9] RFR(S): 8080650: enable stubs to use frame pointers correctly

[Vladimir Kozlov]

On 10/13/15 10:41 PM, Zoltán Majó wrote:
> Hi Vladimir,
>
>
> On 10/13/2015 02:24 PM, Vladimir Kozlov wrote:
>> This seems right.
>>
>> Did you run with -XX:-UseStackBanging? Run at least jtreg tests.
>
> yes, I checked the output of PrintOptoAssembly also with
> -XX:-UseStackBanging and it is working as expected.

Perfect. Thank you for doing that.

Vladimir

>
> I ran all JTREG hotspot tests; all tests pass that pass with and
> unmodified build.
>
> Thank you and best regards,
>
>
> Zoltan
>
>>
>> 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
>>>>>
>>>
>