battleblow / openjdk-jdk11u

BSD port of OpenJDK 11
GNU General Public License v2.0
9 stars 8 forks source link

port to FreeBSD aarch64 #50

Closed MikaelUrankar closed 5 years ago

MikaelUrankar commented 5 years ago

If you want to see the log: http://mikael.urankar.free.fr/FreeBSD/aarch64/openjdk11-aarch64-jdk.log

bsdkurt commented 5 years ago

@MikaelUrankar I would recommend a few things for confirming the stability of port. 1) Configure the build with --with-debug-level=fastdebug and --with-jtreg=<path to jtreg dir> to get debug info + asserts. 2) Build with gmake LOG=debug all to get detailed build log and tests built. 3) Test with gmake run-test-only TEST=":tier1 :tier2"

klaus4 commented 5 years ago

with or without patch http://hg.openjdk.java.net/jdk/jdk/rev/e53ec3b362f4 I get something like : build.log openjdk-jdk11u-freebsd-aarch64/build/bsd-aarch64-normal-server-release/hotspot/variant-server/support/adlc/adlc_run.cmdline /root/Downloads/openjdk-jdk11u-freebsd-aarch64/build/bsd-aarch64-normal-server-release/make-support/failure-logs/hotspot_variant-server_support_adlc_adlc_run.cmdline && exit $exitcode ) ) /usr/local/bin/bash: line 1: 32692 Segmentation fault (core dumped) /root/Downloads/openjdk-jdk11u-freebsd-aarch64/build/bsd-aarch64-normal-server-release/hotspot/variant-server/tools/adlc/adlc -q -T -D_ALLBSD_SOURCE=1 -D_BSDONLY_SOURCE -g -DAARCH64=1 -D_LP64=1 /root/Downloads/openjdk-jdk11u-freebsd-aarch64/build/bsd-aarch64-normal-server-release/hotspot/variant-server/support/adlc/all-ad-src.ad under RPi3 clang --version FreeBSD clang version 8.0.1 (branches/release_80 364487) (based on LLVM 8.0.1) Target: aarch64-unknown-freebsd13.0

since all aarch64 is mostly inconsistent Tier2- environment we should do an agreement on which hardware/OS-Version/compiler work should be done preferred , e.g. Cortex-SBCs(I have RPI3(FreeBSD)/Rock64(OpenBSD/NetBSD), AWS Graviton or ThunderX...... or?

why is this bold? .. don't know

bsdkurt commented 5 years ago

The hs_pid_xxx.log file can have useful information, but to see what's causing the core dump is going to need a fastdebug build in my experience on OpenBSD.

I haven't experimented with OpenBSD aarch64 yet. For the time being I think using the best supported hardware for FreeBSD make sense.

klaus4 commented 5 years ago

The hs_pid_xxx.log file can have useful information, but to see what's causing the core dump is going to need a fastdebug build in my experience on OpenBSD.

I haven't experimented with OpenBSD aarch64 yet. For the time being I think using the best support hardware for FreeBSD make sense.

for FreeBSD that is (only) ThunderX, available here : https://www.packet.com/cloud/servers/c1-large-arm/ 0,50$/hr. , is it worth ? Mikael, what clang/gcc/fbsd-versions did you compile on ?

klaus4 commented 5 years ago

ah, forgot to say : the FreeBSD- bootstrap is not ELF-compatible with aarch64 OpenBSD, would be a hard task on that slow SBC-boards to NFS-bootstrap..

MikaelUrankar commented 5 years ago

You need at least 12-stable (there are some rtld bugs on 11.x and 12.0) But I build in a 11.2 jail (with /libexec/ld-elf.so.1 from 13-current).

cc -v
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)

It builds fine on -current with clang8 on my tx1. I'll try with my rpi3 later today.

MikaelUrankar commented 5 years ago

ah, forgot to say : the FreeBSD- bootstrap is not ELF-compatible with aarch64 OpenBSD, would be a hard task on that slow SBC-boards to NFS-bootstrap..

I managed to bootstrap lang/ghc on my rpi3, it was tedious but not impossible.

klaus4 commented 5 years ago

You need at least 12-stable (there are some rtld bugs on 11.x and 12.0)

well, fortunately there's 12-stable on AWS where we all could work on, if needed : e.g. : ami-0433313756a4e0354 , Region : (EU) Ireland ... didn't search for OpenBSD/NetBSD on all regions but I guess: not available there ( not all Regions have aarch64)

MikaelUrankar commented 5 years ago

@klaus4: which bootstrap did you use? Can you try with this one? http://mikael.urankar.free.fr/FreeBSD/aarch64/bootstrap-openjdk11.tar.xz

klaus4 commented 5 years ago

that's the bootstrap I used, afai-remember, the other bootstrap-file on your website was called 11 but was openjdk12(which can not work as bootstrap for 11), thank you

MikaelUrankar commented 5 years ago

@klaus4: the crash is a bug in adlc (it happens on openjdk11 and openjdk12): https://gist.github.com/MikaelUrankar/6e86f2ecb80e09f1e6c872820cca59db It doesn't crash if the libc is built with MALLOC_PRODUCTION=yes (which is the default on -release branch) I gave a quick look at adlc in jdk11, return code after allocation (malloc) are never checked (it got fixed in openjdk12)... I stopped looking at it after that.

bsdkurt commented 5 years ago

@klaus4: the crash is a bug in adlc (it happens on openjdk11 and openjdk12): https://gist.github.com/MikaelUrankar/6e86f2ecb80e09f1e6c872820cca59db It doesn't crash if the libc is built with MALLOC_PRODUCTION=yes (which is the default on -release branch) I gave a quick look at adlc in jdk11, return code after allocation (malloc) are never checked (it got fixed in openjdk12)... I stopped looking at it after that.

Looking at the related code, I would venture a guess that things have gone wrong in src/hotspot/share/adlc/adlparse.cpp. If it's another clang optimization type issue, you may want to try a slowdebug build which builds at -O0 to see if it reproduces there too. Stepping through the code with gdb and watching for where ADL_Parse->_ptr goes wrong may also help isolate the issue.

klaus4 commented 5 years ago

well, small "Water level" from here: dmesg.txt configure.log.txt build.log.txt

both my own feature-branch with patch from upstream and branch from git clone -b freebsd-aarch64 https://github.com/MikaelUrankar/openjdk-jdk11u.git do the same.

since c1_LIRAssembler_aarch64.cpp is one of the files from the upstream patch I don't know whether to continue with "wild hacking" those files or not :-) [gmake ... -Wno-unnamed-type-template-args .... ] has no effect , to be honest in clang I never succeeded surpressing those warnings/errors, perhaps there is a trick I don't know..
--- edit: --- dtrace was disabled because also ends up with clang-errors( which isn't surprising on aarch)

.. http://hg.openjdk.java.net/jdk/jdk11/raw-file/tip/doc/building.html#building-on-armaarch64 http://hg.openjdk.java.net/jdk/jdk11/raw-file/tip/doc/building.html#building-for-armaarch64 ?

bsdkurt commented 5 years ago

@klaus4 configure with --disable-warnings-as-errors for the time being. I'd also suggest building with gmake LOG=debug all to get detailed build logs that include arguments passed to clang.

klaus4 commented 5 years ago

@klaus4 configure with --disable-warnings-as-errors for the time being. I'd also suggest building with gmake LOG=debug all to get detailed build logs that include arguments passed to clang.

--disable-warnings-as-errors -> ouch ... unbelievable that i forgot this flag :-), thanks

klaus4 commented 5 years ago

@battleblow all patches you comment were imported from the upstream by Mikael : http://hg.openjdk.java.net/jdk/jdk/rev/e53ec3b362f4 (recommended by Kurt above)

Anyway, I'm hanging here right now :

/root/openjdk-jdk11u/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp:245:1: error: no member named 'ExitedWithCode' in namespace 'testing' TEST_OTHER_VM(CollectorPolicy, young_cmd) { ^~~~~~~~~ /root/openjdk-jdk11u/test/hotspot/gtest/unittest.hpp:67:28: note: expanded from macro 'TEST_OTHER_VM' ::testing::ExitedWithCode(0), \


/root/openjdk-jdk11u/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp:267:1: error: no member named 'ExitedWithCode' in namespace 'testing'
TEST_OTHER_VM(CollectorPolicy, old_cmd) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/root/openjdk-jdk11u/test/hotspot/gtest/unittest.hpp:67:28: note: expanded from macro 'TEST_OTHER_VM'
                ::testing::ExitedWithCode(0),                       \
                ~~~~~~~~~~~^
2 errors generated. 

Regards
MikaelUrankar commented 5 years ago

Try with --disable-hotspot-gtest, it's in the FreeBSD ports Makefile

klaus4 commented 5 years ago

well done, Mikael ! after --disable-hotspot-gtest and installing the alsa-libs the release-build succeeded. from my view PR can be merged

if you want further tests from me or make the AWS-AMI public, let me know

configure_make_flags.txt

configure_log.txt

build_log.txt

dmesg.txt

so the next thing for aarch could be a look @ dtrace-implementation

bsdkurt commented 5 years ago

I merged a fix for the adlc segfault and gtest build failure into bsd-port. @MikaelUrankar if you rebase your freebsd-aarch64 branch on bsd-port with these fixes it should correct those issues.

I setup a FreeBSD 13-current aarch64 node at aws and am running a gmake run-test-only TEST=":tier1 :tier2" test now. So far so good with the exception of the issue raised in #51.

bsdkurt commented 5 years ago

@MikaelUrankar oh I forgot to mention, building on FreeBSD 13-current needed a patch to src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp since some #defines changed. I needed this to build there:

diff --git a/src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp b/src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
index 847cbf5e98..eb1c0d5d58 100644
--- a/src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
+++ b/src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp
@@ -1,6 +1,23 @@
 #ifndef CPU_AARCH64_VM_BSD_AARCH64_HPP
 #define CPU_AARCH64_VM_BSD_AARCH64_HPP

+// for FreeBSD-13
+#ifndef ID_AA64PFR0_ADV_SIMD_SHIFT
+#define        ID_AA64PFR0_ADV_SIMD_SHIFT 20
+#endif
+
+#ifndef ID_AA64PFR0_ADV_SIMD_MASK
+#define        ID_AA64PFR0_ADV_SIMD_MASK (0xf << ID_AA64PFR0_ADV_SIMD_SHIFT)
+#endif
+
+#ifndef ID_AA64PFR0_ADV_SIMD
+#define        ID_AA64PFR0_ADV_SIMD(x) ((x) & ID_AA64PFR0_ADV_SIMD_MASK)
+#endif
+
+#ifndef ID_AA64PFR0_ADV_SIMD_IMPL
+#define        ID_AA64PFR0_ADV_SIMD_IMPL (0x0 << ID_AA64PFR0_ADV_SIMD_SHIFT)
+#endif
+

Although perhaps you may want to use the newer names in -current and put in backward compat defines for 11/12 instead of what I did above.

Separately, I still feel the new header src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp doesn't fit well with how Oracle has structured things. After reviewing it more I think the contents of the new header and the FreeBSD specific code in src/hotspot/cpu/aarch64/vm_version_aarch64.cpp should be moved into a new VMVersion method in src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp similar to the way that VM_Version::get_os_cpu_info() is done in src/hotspot/os_cpu/linux_arm/vm_version_linux_arm_32.cpp.

I'll try to find time to code up what I'm suggesting and make a pull request to your fork. I'm not sure if I will be able to pull it off before I go on vacation though.

Edit: fixed get_os_cpu_into() file name.

MikaelUrankar commented 5 years ago

I merged a fix for the adlc segfault and gtest build failure into bsd-port. @MikaelUrankar if you rebase your freebsd-aarch64 branch on bsd-port with these fixes it should correct those issues.

Many thanks. Out of curiosity, how did you debugged the adlc issue?

I setup a FreeBSD 13-current aarch64 node at aws and am running a gmake run-test-only TEST=":tier1 :tier2" test now. So far so good with the exception of the issue raised in #51.

I was thinking of something like this (and merge bsd_aarch64.hpp into vm_version_aarch64.hpp: https://gist.github.com/MikaelUrankar/13f018a2705b6dea7240c8f2ee69f3f5)

@MikaelUrankar oh I forgot to mention, building on FreeBSD 13-current needed a patch to src/hotspot/os_cpu/bsd_aarch64/bsd_aarch64.hpp since some #defines changed. I needed this to build there: Although perhaps you may want to use the newer names in -current and put in backward compat defines for 11/12 instead of what I did above.

I'm aware of the recent change. Anyway, I'm targetting 12.1-RELEASE for this java work and the new define will be MFC'ed by then.

bsdkurt commented 5 years ago

Many thanks. Out of curiosity, how did you debugged the adlc issue?

After confirming the issue existed with slowdebug (ruling out clang opto issues), I built a fastdebug build, but found that adlc was stripped anyway. So I deleted the adlc binary and added this to get a debugable adlc binary:

diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk b/make/hotspot/gensrc/GensrcAdlc.gmk
index 67124ff845..fa84422a0e 100644
--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -75,7 +75,8 @@ ifeq ($(call check-jvm-feature, compiler2), true)
       LIBS := $(ADLC_LIBS), \
       OBJECT_DIR := $(JVM_VARIANT_OUTPUTDIR)/tools/adlc/objs, \
       OUTPUT_DIR := $(JVM_VARIANT_OUTPUTDIR)/tools/adlc, \
-      DEBUG_SYMBOLS := false, \
+      DEBUG_SYMBOLS := true, \
+      STRIP_SYMBOLS := false, \
       DISABLED_WARNINGS_clang := tautological-compare, \
       DISABLED_WARNINGS_solstudio := notemsource, \
   ))

After that it was a pretty typical debug session. I worked my way backwards until I realized the parsing was fine and that ADLParser::cisc_spilling_operand_name_parse() was never called so it lead me back to the constructor for FrameForm.

I was thinking of something like this (and merge bsd_aarch64.hpp into vm_version_aarch64.hpp: https://gist.github.com/MikaelUrankar/13f018a2705b6dea7240c8f2ee69f3f5)

I think I led you astray with my initial recommendation to use os_bsd_aarch64.cpp. There already is a os_cpu/bsd_aarch64/ file for vm_version. Here's a diff along the lines of what I was thinking. It builds but I ran out of disk space so its untested and needs to be cleaned up a bit:

vm_version_bsd_aarch64.diff

I'm heading out for a vacation soon so I don't want to hold up this pull request. With something similar to the diff above I'm happy with the pull request. Thank you for working on this.

bsdkurt commented 5 years ago

I ran out of disk space while running gmake run-test-only TEST=":tier1 :tier2" (I had a second build of the jdk running that used up the space) but here's the output up until it failed:

fbsd-aarch64-testing.log

I haven't had time to review this, but I thought it would be helpful to see which tests have crashes for further investigation.

klaus4 commented 5 years ago

I ran out of disk space ...

:-) I experienced the same , on EC2 you can expand the volume to e.g. 20GB, then in FBSD expand the / partition via gpart, since growfs doesn't work on UFS in the AMI, I typed service growfs onestart and that worked ..

battleblow commented 5 years ago

Okay, looking at moving this forward, can I ask that you rebase the pull request so that there are only two commits in it.

Commit 1: The import of http://hg.openjdk.java.net/jdk/jdk/rev/e53ec3b362f4 Commit 2: BSD aarch64 support

The reason I'm asking this is that I'll need to merge the changes forward into newer versions. This way I'll only need to merge two commits rather nine (which makes it easier to track) while preserving the split between new BSD code and upstream changes, since the upstream changes only need to be merged into 12 and 13 (not 14).

If it's easier, please feel free to do the rebasing on a separate branch and send a new pull request from there.

MikaelUrankar commented 5 years ago

Done.