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

[Zoltán Majó]

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.

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
>>>>
>>