Hi Magnus!
I just tested it and the following change in make/autoconf/flags.m4 is
necessary as well so that gcc is not called with "-m64":
diff -r 18afb2097ada -r 1f28530b1f46 make/autoconf/flags.m4
--- a/make/autoconf/flags.m4 Fri Aug 31 11:43:06 2018 +0200
+++ b/make/autoconf/flags.m4 Fri Aug 31 12:50:02 2018 +0200
@@ -241,7 +241,8 @@
elif test "x$TOOLCHAIN_TYPE" = xsolstudio; then
MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
elif test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
- if test "x$OPENJDK_TARGET_CPU_ARCH" = xx86 ||
+ if test "x$OPENJDK_TARGET_CPU_ARCH" = xx86 &&
+ test "x$OPENJDK_TARGET_CPU" != xx32 ||
test "x$OPENJDK_TARGET_CPU_ARCH" = xsparc ||
test "x$OPENJDK_TARGET_CPU_ARCH" = xppc; then
MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
Adrian
On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote:
> The necroposter strikes back! :-)
>
> I'm currently trying to fix or close all long standing bugs on
> infrastructure/build, and now the time has come to JDK-8165440.
>
> This patch had a bit of bad timing when it was posted, since it could not be
> accepted into mainline due to feature freeze, and there were no other repo to
> accept it.
>
> I adjusted the patch to the current code base (which means that most parts of
> it were not needed). What remains are two files. However, I can't test if
> this works. Matthias, can you verify that this is a working patch for jdk/jdk
> for the gnux32 target? If so, I'll sponsor this patch.
>
> diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4
> --- a/make/autoconf/platform.m4
> +++ b/make/autoconf/platform.m4
> @@ -35,6 +35,10 @@
> VAR_CPU_ARCH=x86
> VAR_CPU_BITS=64
> VAR_CPU_ENDIAN=little
> + case "$host" in *x32)
> + VAR_CPU=x32
> + VAR_CPU_BITS=32
> + esac
> ;;
> i?86)
> VAR_CPU=x86
> @@ -455,6 +459,8 @@
> HOTSPOT_$1_CPU_DEFINE=IA32
> elif test "x$OPENJDK_$1_CPU" = xx86_64; then
> HOTSPOT_$1_CPU_DEFINE=AMD64
> + elif test "x$OPENJDK_$1_CPU" = xx32; then
> + HOTSPOT_$1_CPU_DEFINE=X32
> elif test "x$OPENJDK_$1_CPU" = xsparcv9; then
> HOTSPOT_$1_CPU_DEFINE=SPARC
> elif test "x$OPENJDK_$1_CPU" = xaarch64; then
> diff --git a/src/hotspot/os/linux/os_linux.cpp
> b/src/hotspot/os/linux/os_linux.cpp
> --- a/src/hotspot/os/linux/os_linux.cpp
> +++ b/src/hotspot/os/linux/os_linux.cpp
> @@ -1742,7 +1742,7 @@
>
> #if (defined IA32)
> static Elf32_Half running_arch_code=EM_386;
> -#elif (defined AMD64)
> +#elif (defined AMD64) || defined(X32)
> static Elf32_Half running_arch_code=EM_X86_64;
> #elif (defined IA64)
> static Elf32_Half running_arch_code=EM_IA_64;
>
> /Magnus
>
> On 2016-09-06 01:01, David Holmes wrote:
>> Hi Severin, Matthias,
>>
>> On 5/09/2016 10:16 PM, Severin Gehwolf wrote:
>>> On Mon, 2016-09-05 at 14:03 +0200, Matthias Klose wrote:
>>>> The attached patch adds support for building zero for the x86_64-
>>>> linux-gnux32
>>>> target, having changes in the build system, hotspot and jdk.
>>>>
>>>> - the build system currently only derives the target from
>>>> the cpu in PLATFORM_EXTRACT_VARS_FROM_CPU; that is not enough
>>>> for the new target, which only differs by the ending of the
>>>> triplet. However the $host macro should be available anywhere.
>>>>
>>>> - the hotspot part just handles the new "cpu"
>>>>
>>>> - GensrcX11Wrappers.gmk assumes that there is a black/white
>>>> decision about -m32/-m64. The patch works around it. However
>>>> the real patch should be to get these flags from the build
>>>> system, and not hardcode itself.
>>>>
>>>> - the sysctl system call is unsupported in the x32 kernel, and
>>>> just the include leads to a build error. From my point of view
>>>> the header is not needed. I had successful builds on all other
>>>> targets without including it. If you want to keep the include,
>>>> then it should be guarded with
>>>> #if !(defined(_ILP32) && defined(__x86_64__))
>>>>
>>>> Matthias
>>>
>>> I've filed this bug for this:
>>> https://bugs.openjdk.java.net/browse/JDK-8165440
>>
>> Please note that as a P4 issue this can not be fixed given we have hit RDP1:
>>
>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html
>>
>> Further this is filed as "bug" but seems to clearly be an enhancement, so
>> you would need approval for it to come in post-Feature-Complete.
>>
>> Please consider if this is something that must be fixed for 9 or can be
>> deferred. Otherwise you will need to follow additional approval processes.
>>
>> Sorry.
>>
>> David (just the messenger!)
>>
>>> Unfortunately, I have no way of testing it.
>>>
>>> Cheers,
>>> Severin
>>>
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
