RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM

[Volker Simonis]

Hi Andrew,

could you pleas hold on a little bit.

I just found out that for x86_64 we additionally need -fno-devirtualize
when compiling 'assembler_x86.cpp'. Without the option, the compilation of
"Assembler::reachable(AddressLiteral adr)" is totally broken:

   0x7ffff6046910 <_ZN9Assembler9reachableE14AddressLiteral>:    push   %rbp
   0x7ffff6046911 <_ZN9Assembler9reachableE14AddressLiteral+1>:    mov
%rsp,%rbp
   0x7ffff6046914:    data32 data32 nopw %cs:0x0(%rax,%rax,1)
   0x7ffff6046920 <_ZN9Assembler19is_polling_page_farEv>:    mov
0x12d7e69(%rip),%rax

As you can see it only contains two instructions before it unconditionally
falls into 'Assembler::is_polling_page_far()'

Maybe we should do some more thorough tests on both, x86 and x86_64 with
these settings to avoid follow-up changes.

What bothers me however is the fact that we now get this sever error at
several places in the OpenJDK while it doesn't seem to affect others and I
can not see what's special in the coding that triggers the misbehavior?

Regards,
Volker



On Thu, Apr 24, 2014 at 5:10 AM, Andrew Hughes <gnu.andrew at redhat.com>wrote:

> Webrev: http://cr.openjdk.java.net/~andrew/8041658/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8041658
> Earlier discussion:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013577.html
>
> It is necessary to pass -fno-devirtualize to gcc when building
> macroAssembler_x86.o with
> gcc 4.9.0, as otherwise a return statement is missing in
> MacroAssembler::jump_cc(Assembler::Condition, AddressLiteral) and control
> flow enters whatever
> method happens to follow it.
> --
> Andrew :)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: 248BDC07 (https://keys.indymedia.org/)
> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
>
>