jdk9/hs repo build issues for s390x

[Schmidt, Lutz]

Hi, 


the below error points to an instruction pattern detection issue (what a
complicated name :-)). There is a ³Call Far Patchable² at the examined
address, because
   c0e5fffdd3c0 translates into BRASL R14,0xfffdd3c0
The detection code expects the BRASL to be prepended with a nop (0x0700).
Either, the nop isn¹t there or the examined address is incorrect (two
bytes too high).

Im not sure if the hs_err_pid48608.log could help here. What we would need
is a storage dump/disassembly around the examined address.

Regards, Lutz


On 04.11.16, 20:12, "s390x-port-dev on behalf of Volker Simonis"
<s390x-port-dev-bounces at openjdk.java.net on behalf of
volker.simonis at gmail.com> wrote:

>On Fri, Nov 4, 2016 at 4:38 PM, Shahid Shaikh <shahid at us.ibm.com> wrote:
>>
>> Hi,
>>
>> We are trying to build OpenJDK9 for s390x from 'jdk9/hs' repository
>>(where
>> the s390x code changes has been merged). However build is failing with
>> following error:
>>
>> On RHEL7.2 / SLES12SP1:
>> Compiling 1 files for java.se.ee
>> Compiling 235 files for jdk.xml.ws
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> Compiling 4 files for BUILD_JIGSAW_TOOLS
>> MacroAssembler::get_dest_of_call_far_patchable_at has a problem at
>> 0x2003009c900:
>> not a call_far_patchable: c0e5fffdd3c0e320 f0500004c0f40000, len = 8
>> Could not load hsdis-s390x.so; library not loadable; PrintAssembly is
>> disabled
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (macroAssembler_s390.cpp:2532), pid=48608, tid=48614
>> #  Error: ShouldNotReachHere()
>> #
>> # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal
>> +0-2016-11-03-151506..OpenJDK9)
>> # Java VM: OpenJDK 64-Bit Server VM (9-internal
>> +0-2016-11-03-151506..OpenJDK9, mixed mode, tiered, compressed oops,
>>serial
>> gc, linux-s390x)
>> # Core dump will be written. Default location: Core dumps may be
>>processed
>> with "/usr/share/apport/apport %p %s %c %P" (or dumping
>> to /SSWorkspace/OpenJDK9/make/core.48608)
>> #
>> # An error report file with more information is saved as:
>> # /SSWorkspace/OpenJDK9/make/hs_err_pid48608.log
>> #
>> # Compiler replay data is saved as:
>> # /SSWorkspace/OpenJDK9/make/replay_pid48608.log
>> #
>
>Hi Shahid,
>
>sorry to hear you have problems with the port.
>
>Could you please send us the two /hs_err_pid48608.log and
>replay_pid48608.log files so we can further investigate the error.
>They will be stripped from the mailing list, but if you do a
>"reply-all" to this mail, my colleagues and I will get them.
>
>We've detected one problem with the port and currently do our nightly
>builds (see http://cr.openjdk.java.net/~simonis/ppc-aix-port/) with
>the attached patch. You could try it but it doesn't seems to be
>related to your problem.
>
>Could you please also send the output of configure along with the log
>files so we can see what tools you are using.
>
>> # If you would like to submit a bug report, please visit:
>> #   http://bugreport.java.com/bugreport/crash.jsp
>> #
>> gmake[3]: ***
>> 
>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/jdk/_packa
>>ges_attribute.done]
>>  Aborted (core dumped)
>> gmake[2]: *** [exploded-image-optimize] Error 1
>>
>> On Ubuntu 16.04:
>> Creating libTestJNI.so from 1 file(s)
>> Creating FPRegs from 1 file(s)
>> Creating invoke from 1 file(s)
>> 
>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes
>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o:
>>  In function `closeHandle':
>> 
>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>Regs.c:48:
>>  undefined reference to `dlclose'
>> 
>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>Regs.c:49:
>>  undefined reference to `dlerror'
>> 
>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes
>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o:
>>  In function `loadJVM':
>> 
>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>Regs.c:69:
>>  undefined reference to `dlopen'
>> 
>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>Regs.c:77:
>>  undefined reference to `dlsym'
>> 
>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>Regs.c:88:
>>  undefined reference to `dlerror'
>> collect2: error: ld returned 1 exit status
>> JtregNative.gmk:111: recipe for target
>> 
>>'/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te
>>st/hotspot/jtreg/native/bin/FPRegs'
>>  failed
>> make[3]: ***
>> 
>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te
>>st/hotspot/jtreg/native/bin/FPRegs]
>>  Error 1
>> make[2]: *** [build-test-hotspot-jtreg-native] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> make/Main.gmk:398: recipe for target 'build-test-hotspot-jtreg-native'
>> failed
>> Creating support/symbols/ct.sym
>>
>> ERROR: Build failed for target 'all' in configuration
>> 'linux-s390x-normal-server-release' (exit code 2)
>> Stopping sjavac server
>>
>
>So this seems to be a different problem. It is a known bug that the
>tests are currently not completely working. Goetz still has a bug open
>for this (https://bugs.openjdk.java.net/browse/JDK-8166837) but you
>can already find a webrev which should fix the issue and which should
>hopefully be pushed soon here:
>
>http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02
>
>Can you please try to just build the "images" target and report if
>that succeeds? If it does, you should find a complete image under
>images/jdk which you could use for testing.
>
>If at least the "images" target succeeds on Ubuntu than the other
>build failure seems to be related to RHEL7.2 / SLES12SP1. Maybe they
>use another version of GCC which has some problems?
>
>Regards,
>Volker
>
>>
>> We are using following steps to build OpenJDK9:
>>    hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9
>>    cd OpenJDK9
>>    bash ./get_source.sh
>>    unset JAVA_HOME
>>    export LANG=C
>>    export
>>    
>>PATH="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.s390x/bin:$
>>    {PATH}"
>>    bash ./configure --with-jvm-variants=server
>>--disable-warnings-as-errors
>>    make all
>>
>
>That sounds reasonable.
>
>>
>> We tried same on x86 machine and got the same build failure.
>>
>
>That's strange. I just saw that we also use --with-jtreg on the
>configure command line which points to the latest version of JTreg
>we've built. Maybe that's the problem if you have build failures on
>x86? Again, try to build 'images' first and only if that succeeds try
>'test-images' or 'all'.
>
>Regards,
>Volker
>
>PS: could you (and your colleagues) please subscribe to the list.
>Otherwise you mails will be on hold until I moderate them.
>
>> Please let us know if we are missing anything here.
>>
>> Thanks & Regards,
>> Shahid