[RFR] jdk9.0.4+12 + functionality
Andrey Petushkov
andrey.petushkov at gmail.com
Wed Apr 11 14:22:35 UTC 2018
> On 11 Apr 2018, at 15:05, Edward Nevill <edward.nevill at gmail.com> wrote:
>
> On Wed, 2018-04-11 at 11:37 +0300, Andrey Petushkov wrote:
>> Dear Ed,
>>
>> I’ve uploaded the workdir w/o .hg of the jdk9.0.4+12 update files to http://cr.openjdk.java.net/~apetushkov/aarch32jdk9.0.4%2b12/azul-aarch32-jdk9-u12.tgz
>> I’ve checked that subsequent azul’s functionality patch applies trivially. Hope that works
>>
>> Regards,
>> Andrey
>>
>
> Thanks for that Andrey. Some comments on the merge.
>
> === ./src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.c
>
> 1) it has
>
> #if defined(i386) || defined(amd64) || defined(sparc) || defined(sparcv9) | defined(ppc64) || defined(ppc64le) || defined(aarch64) | defined(aarch32)
> -----------------------------------------------------------------------------------------------------------------------------------^
>
> Note the '|' rather than '||' for aarch32
>
> I think this is the same in the jdk9 repo, but if it could be fixed.
Yes, I did not fix specifically since it should work either way and ppc64 is for some reason is using single | as well. Indeed for sake of consistency I agree, let’s use ||
>
> 2) the following seems to have been deleted
>
> #ifdef aarch32
> #define NPRGREG 32
> #endif
>
> This is present in the jdk9 tree but not your merged tree
Thank you, will fix (look like merge mistake - there is no your changeset from 2015 in file history)
>
> === ./make/linux/makefiles/aarch32.make
>
> This file seems to be vestigial. All the other <arch>.make files have been removed in jdk9u
Likely was some trivial merge so it did not caught my sight. Will remove. The ./make/linux/platform_aarch32 as well, right?
>
> === ./src/share/vm/utilities/macros.hpp
>
> // Note: There are three ARM ports. They set the following in the makefiles:
> // 1. Closed 32-bit port: -DARM -DARM32 -DTARGET_ARCH_arm
> // 2. Closed 64-bit port: -DARM -DAARCH64 -D_LP64 -DTARGET_ARCH_arm
> // 3. Open 64-bit port: -DAARCH64 -D_LP64 -DTARGET_ARCH_aaarch64
> #ifdef ARM
> #define ARM_ONLY(code) code
> #define NOT_ARM(code)
> #else
> #define ARM_ONLY(code)
> #define NOT_ARM(code) code
> #endif
>
> Should this be?
>
> #if defined(ARM) || defined(AARCH32)
>
> This is how it is in the jdk9 port.
This part is reworked in the “functionality” patch. So I did not pay attention here while it looks like a merge bug again. Also note the duplicate “ARM32 || AARCH32” block here
>
> === common/autoconf/platform.m4
>
> The following
>
> OPENJDK_$1_CPU_OSARCH="$OPENJDK_$1_CPU"
> if test "x$OPENJDK_$1_OS" = xlinux && test "x$OPENJDK_$1_CPU" = xx86; then
> # On linux only, we replace x86 with i386.
> OPENJDK_$1_CPU_OSARCH="i386"
> elif test "x$OPENJDK_$1_OS" != xmacosx && test "x$OPENJDK_$1_CPU" = xx86_64; then
> # On all platforms except macosx, we replace x86_64 with amd64.
> OPENJDK_TARGET_CPU_OSARCH="amd64"
> elif test "x$OPENJDK_TARGET_CPU" = xaarch32; then
> OPENJDK_TARGET_CPU_OSARCH="arm"
> fi
> AC_SUBST(OPENJDK_$1_CPU_OSARCH)
>
> has been rewritten in jdk9u, note that it uses OPENJDK_$1_CPU rather than OPENJDK_TARGET_CPU so I think this should read
>
> OPENJDK_$1_CPU_OSARCH="$OPENJDK_$1_CPU"
> if test "x$OPENJDK_$1_OS" = xlinux && test "x$OPENJDK_$1_CPU" = xx86; then
> # On linux only, we replace x86 with i386.
> OPENJDK_$1_CPU_OSARCH="i386"
> elif test "x$OPENJDK_$1_OS" != xmacosx && test "x$OPENJDK_$1_CPU" = xx86_64; then
> # On all platforms except macosx, we replace x86_64 with amd64.
> OPENJDK_$1_CPU_OSARCH="amd64"
> elif test "x$OPENJDK_$1_CPU" = xaarch32; then
> OPENJDK_$1_CPU_OSARCH="arm"
> fi
> AC_SUBST(OPENJDK_$1_CPU_OSARCH)
Merge error on my side, sorry
>
> === make/copy/Copy-java.base.gmk
>
> It does the following
>
> COPY_JVM_CFG_FILE := true
>
> ifeq ($(COPY_JVM_CFG_FILE), true)
> $(JVMCFG): $(JVMCFG_SRC)
> $(call install-file)
>
> This is not anything to do with the merge but is fugly and needs to be fixed sometime! So I am just making a note of it here. Maybe I should file a bug report.
Right but let’s please indeed address this separately
I’ve updated the tgz with fixes for all above
So how we proceed then? We should still have some way of pushing jdk9u history into our repo, right?
Thanks,
Andrey
>
> All the best,
> Ed.
>
More information about the aarch32-port-dev
mailing list