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

[Zoltán Majó]

Thank you reviewing this, Vladimir!

Best regards,


Zoltan

On 10/13/2015 04:43 PM, Vladimir Kozlov wrote:
> 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
>>>>>>
>>>>
>>