From dingli at iscas.ac.cn Fri Apr 1 00:15:04 2022 From: dingli at iscas.ac.cn (Dingli Zhang) Date: Fri, 1 Apr 2022 08:15:04 +0800 Subject: Different macro definition between make and make images when cross compiling In-Reply-To: <62039d73d5ad4cac8e094d45ab422f59@huawei.com> References: <62039d73d5ad4cac8e094d45ab422f59@huawei.com> Message-ID: <49E9EF21-E9C2-4FE0-9565-A0CC544B28E0@iscas.ac.cn> Thanks Yadong! In fact the cause of the problem is indeed the build jdk. Regards, Dingli > On Mar 31, 2022, at 17:52, wangyadong (E) wrote: > > Hi, Dingli, > > Obviously, make install or make images did more work than make. > > In make/Main.gmk, you will see comments below: > > # Jmods cannot be created until we have the jmod tool ready to run. During > # a normal build we run it from the exploded image, but when cross compiling > # it's run from the buildjdk, which is either created at build time or user > # supplied. > > If you did not indicate the build jdk by configuring with --with-build-jdk, a new one will be created at the build time, targeting on the platform where the building work happened. > > With your example, make install met a compilation error when you creating a build jdk on the host platform. > > Best regards, > Yadong > > -----Original Message----- > From: riscv-port-dev [mailto:riscv-port-dev-retn at openjdk.java.net] On Behalf Of Dingli Zhang > Sent: Thursday, March 31, 2022 2:37 PM > To: riscv-port-dev at openjdk.java.net > Subject: Different macro definition between make and make images when cross compiling > > Hi, thanks everyone for upstreaming! > I built jdk with cross compiling follow the guide here: > http://cr.openjdk.java.net/~fyang/openjdk-riscv-port/BuildRISCVJDK.md > > > It works and is very convenient but I have a small question, is there any different macro definition when buid jdk between make and make images? > I use https://github.com/openjdk/jdk/tree/eeca3a31559c2e334958c6d929cff8eb350c32a3 and apply this patch: > diff --git a/src/hotspot/share/runtime/thread.inline.hpp b/src/hotspot/share/runtime/thread.inline.hpp > index 92dfdfa3dbe..b9e50eeb597 100644 > --- a/src/hotspot/share/runtime/thread.inline.hpp > +++ b/src/hotspot/share/runtime/thread.inline.hpp > @@ -155,6 +155,7 @@ inline JavaThreadState JavaThread::thread_state() const { > // Threads::create_vm() for size checks. > return (JavaThreadState) Atomic::load_acquire((volatile jint*)&_thread_state); #else > + throw "Should not reach here!"; > return _thread_state; > #endif > } > > > It can build and run java -version successfully with 'make' but will throw exception with 'make images': > In file included from src/hotspot/share/interpreter/bootstrapInfo.cpp:41:0: > src/hotspot/share/runtime/thread.inline.hpp: In member function 'JavaThreadState JavaThread::thread_state() const': > src/hotspot/share/runtime/thread.inline.hpp:158:9: error: exception handling disabled, use -fexceptions to enable > throw "Should not reach here!"; > ^~~~~~~~~~~~~~~~~~~~~~~~ > At global scope: > cc1plus: warning: unrecognized command line option '-Wno-cast-function-type' > gmake[4]: *** [/jdk/build/linux-riscv64-server-release/buildjdk/hotspot/variant-server/libjvm/objs/bootstrapInfo.o] Error 1 > gmake[4]: *** Waiting for unfinished jobs.... > lib/CompileJvm.gmk:146: recipe for target '/jdk/build/linux-riscv64-server-release/buildjdk/hotspot/variant-server/libjvm/objs/bootstrapInfo.o' failed [buildjdk] Compiling 186 files for BUILD_TOOLS_JDK [buildjdk] Compiling 2 files for COMPILE_DEPEND [buildjdk] Compiling 11 properties into resource bundles for java.logging [buildjdk] Compiling 5 properties into resource bundles for jdk.jlink [buildjdk] Compiling 3 properties into resource bundles for jdk.jlink [buildjdk] Compiling 1 properties into resource bundles for jdk.jlink [buildjdk] Compiling 2 files for BUILD_BREAKITERATOR_BASE [buildjdk] Compiling 2 files for BUILD_BREAKITERATOR_LD [buildjdk] Compiling 11 properties into resource bundles for java.base [buildjdk] Compiling 6 properties into resource bundles for java.base > Main.gmk:252: recipe for target 'hotspot-server-libs' failed > gmake[3]: *** [hotspot-server-libs] Error 1 > gmake[3]: *** Waiting for unfinished jobs.... > make/Main.gmk:554: recipe for target 'create-buildjdk-interim-image' failed > gmake[2]: *** [create-buildjdk-interim-image] Error 1 > > ERROR: Build failed for target 'images' in configuration 'linux-riscv64-server-release' (exit code 2) Stopping sjavac server > > === Output from failing command(s) repeated here === > * For target buildjdk_hotspot_variant-server_libjvm_objs_bootstrapInfo.o: > In file included from src/hotspot/share/interpreter/bootstrapInfo.cpp:41:0: > src/hotspot/share/runtime/thread.inline.hpp: In member function 'JavaThreadState JavaThread::thread_state() const': > src/hotspot/share/runtime/thread.inline.hpp:158:9: error: exception handling disabled, use -fexceptions to enable > throw "Should not reach here!"; > ^~~~~~~~~~~~~~~~~~~~~~~~ > At global scope: > cc1plus: warning: unrecognized command line option '-Wno-cast-function-type' > > * All command lines available in /jdk/build/linux-riscv64-server-release/make-support/failure-logs. > === End of repeated output === > > === Make failed targets repeated here === > lib/CompileJvm.gmk:146: recipe for target '/jdk/build/linux-riscv64-server-release/buildjdk/hotspot/variant-server/libjvm/objs/bootstrapInfo.o' failed > Main.gmk:252: recipe for target 'hotspot-server-libs' failed > make/Main.gmk:554: recipe for target 'create-buildjdk-interim-image' failed === End of repeated output === > > Hint: Try searching the build log for the name of the first failed target. > Hint: See doc/building.html#troubleshooting for assistance. > > /jdk/make/Init.gmk:310: recipe for target 'main' failed > make[1]: *** [main] Error 1 > /jdk/make/Init.gmk:186: recipe for target 'images' failed > make: *** [images] Error 2 > > > I think it caused by the undefined macro 'RISCV64'. While the origin code build works with make/make images, it's odd that a macro that should be defined isn't defined. > Is this problem normal, or is it caused by cross compiling or make images? > > Thanks, Dingli From xiejunfeng3 at huawei.com Tue Apr 12 09:01:40 2022 From: xiejunfeng3 at huawei.com (xiejunfeng (C)) Date: Tue, 12 Apr 2022 09:01:40 +0000 Subject: Zero support for 32-bit RISC-V Message-ID: <4386aaba00304842befff74d7f68e0c3@huawei.com> Hi, I'm adding Zero support for the 32-bit RISC-V architecture. I have made an initial patch and it has been successfully cross-compiled: $ qemu-riscv32 -L /path/to/riscv32/sysroot /patch/to/riscv-port/openjdk-19-internal/bin/java --version openjdk 19-internal 2022-09-20 OpenJDK Runtime Environment (build 19-internal-adhoc.xiejunfeng.riscv-port) OpenJDK Zero VM (build 19-internal-adhoc.xiejunfeng.riscv-port, interpreted mode) I am currently testing this. You can get the patch here: https://github.com/xiejf2020/riscv-port/commit/20db4468b3738f0daef75ac59c1e7a016556b712 . Best regards, Junfeng From shade at redhat.com Wed Apr 13 08:37:34 2022 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 Apr 2022 10:37:34 +0200 Subject: Zero support for 32-bit RISC-V In-Reply-To: <4386aaba00304842befff74d7f68e0c3@huawei.com> References: <4386aaba00304842befff74d7f68e0c3@huawei.com> Message-ID: <77bc0de7-3930-ca23-9bdc-e3f09a96051f@redhat.com> On 4/12/22 11:01, xiejunfeng (C) wrote: > Hi, I'm adding Zero support for the 32-bit RISC-V architecture. > > I have made an initial patch and it has been successfully cross-compiled: > > $ qemu-riscv32 -L /path/to/riscv32/sysroot /patch/to/riscv-port/openjdk-19-internal/bin/java --version > openjdk 19-internal 2022-09-20 > OpenJDK Runtime Environment (build 19-internal-adhoc.xiejunfeng.riscv-port) > OpenJDK Zero VM (build 19-internal-adhoc.xiejunfeng.riscv-port, interpreted mode) > > I am currently testing this. > > You can get the patch here: https://github.com/xiejf2020/riscv-port/commit/20db4468b3738f0daef75ac59c1e7a016556b712 . That looks fine. I think you can/should PR this to upstream JDK. The SYS_futex -> SYS_futex_time64 aliasing looks a bit odd, but I think many other projects, including gcc, wasm and others made the similar thing for riscv32. -- Thanks, -Aleksey From xiejunfeng3 at huawei.com Fri Apr 15 03:14:07 2022 From: xiejunfeng3 at huawei.com (xiejunfeng (C)) Date: Fri, 15 Apr 2022 03:14:07 +0000 Subject: Zero support for 32-bit RISC-V Message-ID: <2828b32d728c4b5c89246126d1448a26@huawei.com> Thanks Aleksey, I'll create PR later. Regards, Junfeng ----- Original Message----- To: Aleksey Shipilev [mailto:shade at redhat.com] Sent: 2022/4/13 16:38 From: xiejunfeng (C) ; riscv-port-dev at openjdk.java.net Subject: Re: Zero support for 32-bit RISC-V On 4/12/22 11:01, xiejunfeng (C) wrote: > Hi, I'm adding Zero support for the 32-bit RISC-V architecture. > > I have made an initial patch and it has been successfully cross-compiled: > > $ qemu-riscv32 -L /path/to/riscv32/sysroot > /patch/to/riscv-port/openjdk-19-internal/bin/java --version openjdk > 19-internal 2022-09-20 OpenJDK Runtime Environment (build > 19-internal-adhoc.xiejunfeng.riscv-port) > OpenJDK Zero VM (build 19-internal-adhoc.xiejunfeng.riscv-port, > interpreted mode) > > I am currently testing this. > > You can get the patch here: https://github.com/xiejf2020/riscv-port/commit/20db4468b3738f0daef75ac59c1e7a016556b712 . That looks fine. I think you can/should PR this to upstream JDK. The SYS_futex -> SYS_futex_time64 aliasing looks a bit odd, but I think many other projects, including gcc, wasm and others made the similar thing for riscv32. -- Thanks, -Aleksey From dingli at iscas.ac.cn Thu Apr 21 01:07:42 2022 From: dingli at iscas.ac.cn (Dingli Zhang) Date: Thu, 21 Apr 2022 09:07:42 +0800 Subject: Fix bitset of push_reg/pop_reg in MacroAssembler::call_native_base Message-ID: <70A968EA-3F12-48D1-9929-0A605EC3CD5C@iscas.ac.cn> Hi, I found a small problem in src/hotspot/cpu/riscv/macroAssembler_riscv.cpp: void MacroAssembler::call_native_base(address entry_point, Label *retaddr) { Label E, L; int32_t offset = 0; push_reg(0x80000040, sp); // push << t0 & xmethod >> to sp movptr_with_offset(t0, entry_point, offset); jalr(x1, t0, offset); if (retaddr != NULL) { bind(*retaddr); } pop_reg(0x80000040, sp); // pop << t0 & xmethod >> from sp } Bitset of '0x80000040' operates << t1 & xmethod >> here, I think it should be '0x80000020' for << t0 & xmethod >>. I pushed a small patch here: https://github.com/DingliZhang/jdk/commit/6a52ec04b0582b8f4219d6a3e9b7ab64e7a97de3 Best regards, Dingli From jiangfeilong at huawei.com Thu Apr 21 03:14:49 2022 From: jiangfeilong at huawei.com (jiangfeilong) Date: Thu, 21 Apr 2022 03:14:49 +0000 Subject: Fix bitset of push_reg/pop_reg in MacroAssembler::call_native_base In-Reply-To: <70A968EA-3F12-48D1-9929-0A605EC3CD5C@iscas.ac.cn> References: <70A968EA-3F12-48D1-9929-0A605EC3CD5C@iscas.ac.cn> Message-ID: Hi Dingli, Looks like it is a typo. Here we want to save t0 and xmethod (x5 and x31), which should be `0x80000020`. I will help create an issue and add you as the co-author in the pull request. Thanks, Feilong -----Original Message----- From: riscv-port-dev On Behalf Of Dingli Zhang Sent: Thursday, April 21, 2022 9:08 AM To: riscv-port-dev at openjdk.java.net Subject: Fix bitset of push_reg/pop_reg in MacroAssembler::call_native_base Hi, I found a small problem in src/hotspot/cpu/riscv/macroAssembler_riscv.cpp: void MacroAssembler::call_native_base(address entry_point, Label *retaddr) { Label E, L; int32_t offset = 0; push_reg(0x80000040, sp); // push << t0 & xmethod >> to sp movptr_with_offset(t0, entry_point, offset); jalr(x1, t0, offset); if (retaddr != NULL) { bind(*retaddr); } pop_reg(0x80000040, sp); // pop << t0 & xmethod >> from sp } Bitset of '0x80000040' operates << t1 & xmethod >> here, I think it should be '0x80000020' for << t0 & xmethod >>. I pushed a small patch here: https://github.com/DingliZhang/jdk/commit/6a52ec04b0582b8f4219d6a3e9b7ab64e7a97de3 Best regards, Dingli From dingli at iscas.ac.cn Thu Apr 21 03:45:59 2022 From: dingli at iscas.ac.cn (Dingli Zhang) Date: Thu, 21 Apr 2022 11:45:59 +0800 Subject: Fix bitset of push_reg/pop_reg in MacroAssembler::call_native_base In-Reply-To: References: <70A968EA-3F12-48D1-9929-0A605EC3CD5C@iscas.ac.cn> Message-ID: > On Apr 21, 2022, at 11:14, jiangfeilong wrote: > > Hi Dingli, > > Looks like it is a typo. Here we want to save t0 and xmethod (x5 and x31), which should be `0x80000020`. > I will help create an issue and add you as the co-author in the pull request. > > Thanks, Feilong > > -----Original Message----- > From: riscv-port-dev On Behalf Of Dingli Zhang > Sent: Thursday, April 21, 2022 9:08 AM > To: riscv-port-dev at openjdk.java.net > Subject: Fix bitset of push_reg/pop_reg in MacroAssembler::call_native_base > > Hi, I found a small problem in src/hotspot/cpu/riscv/macroAssembler_riscv.cpp: > > void MacroAssembler::call_native_base(address entry_point, Label *retaddr) { > Label E, L; > int32_t offset = 0; > push_reg(0x80000040, sp); // push << t0 & xmethod >> to sp > movptr_with_offset(t0, entry_point, offset); > jalr(x1, t0, offset); > if (retaddr != NULL) { > bind(*retaddr); > } > pop_reg(0x80000040, sp); // pop << t0 & xmethod >> from sp > } > > Bitset of '0x80000040' operates << t1 & xmethod >> here, I think it should be '0x80000020' for << t0 & xmethod >>. > > I pushed a small patch here: https://github.com/DingliZhang/jdk/commit/6a52ec04b0582b8f4219d6a3e9b7ab64e7a97de3 > > Best regards, > Dingli Hi Feilong, Thanks for reply! I will start tier1 test on developing board after your issue. Best regards, Dingli From Pengfei.Li at arm.com Wed Apr 27 10:52:30 2022 From: Pengfei.Li at arm.com (Pengfei Li) Date: Wed, 27 Apr 2022 10:52:30 +0000 Subject: FW: RFR: 8285630: Fix a configure error in RISC-V cross build In-Reply-To: <8nOY-PuXWov02qJbQXiwMqVVCSdqo-epK3PTIAbxAho=.fca8789d-691b-4c17-84b6-b127526b1c0d@github.com> References: <8nOY-PuXWov02qJbQXiwMqVVCSdqo-epK3PTIAbxAho=.fca8789d-691b-4c17-84b6-b127526b1c0d@github.com> Message-ID: Hi, May I have a review of this fix for RISC-V cross build? https://github.com/openjdk/jdk/pull/8420 > We are trying to cross build a RISC-V version of OpenJDK. We specified `-- > openjdk-target=riscv64-linux-gnu` after `bash configure` but got an error > message. > > > configure: error: /usr/bin/bash /home/ent- > user/jdk_src/make/autoconf/build-aux/config.sub riscv64-linux-gnu failed > configure exiting with result code 1 > > > It shows the processing of `riscv64-linux-gnu` in script `config.sub` fails. We > see `config.sub` calls another script `autoconf-config.sub` to validate and > canonicalize a configuration type. The validation fails here because > `autoconf-config.sub` is a quite old version and has no RISC-V support inside. > Comments in those scripts tell us patching the autoconf script is not a good > idea so we add a fix in `config.sub` in this patch. > > We have verified RISC-V cross build succeeds after this change. As we are not > quite familiar with the build system, please let us know if this is the best way > to fix. > > ------------- > > Commit messages: > - 8285630: Fix a configure error in RISC-V cross build > > Changes: https://git.openjdk.java.net/jdk/pull/8420/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8420&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8285630 > Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/8420.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/8420/head:pull/8420 > > PR: https://git.openjdk.java.net/jdk/pull/8420 -- Thanks, Pengfei