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

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Oct 12 14:25:00 UTC 2015


The code which does not do stack banging seems incorrect - RSP is 
modified before it is saved in RBP:

      subptr_imm32(rsp, framesize);

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