Bug 243182

Summary: java/openjdk11: add bootstrap and fix compilation for powerpc64 elfv2
Product: Ports & Packages Reporter: Piotr Kubaj <pkubaj>
Component: Individual Port(s)Assignee: freebsd-java (Nobody) <java>
Status: Closed FIXED    
Severity: Affects Some People CC: frebsd-java, glewis, marklmi26-fbsd, mikael, powerpc
Priority: --- Flags: bugzilla: maintainer-feedback? (java)
Version: Latest   
Hardware: powerpc   
OS: Any   
Attachments:
Description Flags
patch
none
v2 pkubaj: maintainer-approval? (frebsd-java)

Description Piotr Kubaj freebsd_committer freebsd_triage 2020-01-08 11:26:31 UTC
Created attachment 210525 [details]
patch

Add bootstrap for powerpc64 elfv2. This patch also adds -elfv1 suffix to elfv1 file, so please rename it in MASTER_SITES.

Because of issue with macros in precompiled.hpp, --disable-precompiled-headers is necessary.

Since openjdk compiles for elfv1 by default on big-endian ppc64, use a patch to compile for elfv2.
Comment 1 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-08 11:31:36 UTC
Bootstrap available at https://anongoth.pl/bootstrap-openjdk11-powerpc64-elfv2-11.0.5.10.1.tar.xz
Comment 2 Mikael Urankar freebsd_committer freebsd_triage 2020-01-08 12:06:39 UTC
It needs a patch for the gcc case:
http://mikael.urankar.free.fr/FreeBSD/powerpc64/openjdk11_patch-ppc64-elfv2
Comment 3 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-08 12:40:56 UTC
(In reply to mikael.urankar from comment #2)
elfv2 uses clang.
Comment 4 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-08 12:51:40 UTC
Actually, since flags-cflags.m4 contains separate entries for gcc and clang, we could assume that elfv1 always uses gcc and elfv2 always uses clang.

This will make it possible to omit EXTRA_PATCHES and apply this patch everywhere, which simplifies things.
Comment 5 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-08 12:53:44 UTC
Created attachment 210529 [details]
v2

Assume elfv1 -> gcc, elfv2 -> clang.
Comment 6 Greg Lewis freebsd_committer freebsd_triage 2020-01-14 04:04:41 UTC
Comment on attachment 210529 [details]
v2

I could be wrong, but doesn't this break older FreeBSD versions and machines?

I have a PowerMac G5 running FreeBSD 11.x.  My understanding is that ELFv2 ABI is FreeBSD 13 and higher and that using -mtune=power5 would break the G5 as its roughly a Power4.
Comment 7 Greg Lewis freebsd_committer freebsd_triage 2020-01-14 04:06:45 UTC
Also, is it actually a good assumption that gcc = elfv1 and clang = elfv2?  It seems like gcc may be updated to support elfv2, which would break that assumption.
Comment 8 Mikael Urankar freebsd_committer freebsd_triage 2020-01-14 07:15:13 UTC
(In reply to Greg Lewis from comment #6)
mtune=power5 is the default flag for ppc/gcc:
https://github.com/battleblow/openjdk-jdk11u/blob/bsd-port/make/autoconf/flags-cflags.m4#L751

I don't see any ill effect on my G5.
Comment 9 Mark Millard 2020-01-14 07:44:24 UTC
(In reply to mikael.urankar from comment #8)

My expectation:

-mtune= controls instruction sequencing for optimization
but does not add the more modern instructions as
possibilities (of itself).

-mcpu= (and likely some others) does add the more modern
instructions as possibilities (and may do more as well).
Comment 10 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-14 10:21:12 UTC
(In reply to Greg Lewis from comment #7)
Base GCC doesn't support ELFv2.
Comment 11 Greg Lewis freebsd_committer freebsd_triage 2020-01-15 04:50:02 UTC
Thanks for the explanations everyone.

Piotr, I realise the base gcc doesn't supoprt elfv2, but what about later gcc from ports, e.g. gcc9?
Comment 12 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-15 08:38:55 UTC
(In reply to Greg Lewis from comment #11)
Sure, GCC supports ELFv2 since 4.8.3 (https://www.gnu.org/software/gcc/gcc-4.8/changes.html). But FreeBSD/powerpc64 with ELFv2 uses Clang.
From java/openjdk11/Makefile:
.if ${COMPILER_TYPE} == gcc
USE_GCC=        yes
CONFIGURE_ARGS+=        --with-extra-ldflags="-Wl,-rpath=${LOCALBASE}/lib/gcc${GCC_DEFAULT} -L${LOCALBASE}/lib/gcc${GCC_DEFAULT}" \
                        --with-extra-cflags="-Wl,-rpath=${LOCALBASE}/lib/gcc${GCC_DEFAULT}" \
                        --with-extra-cxxflags="-Wl,-rpath=${LOCALBASE}/lib/gcc${GCC_DEFAULT}"
.else
MAKE_ENV+=      USE_CLANG=true
.endif

So new GCC from ports (able to use ELFv2) will be used only when GCC is used in the first place (base GCC, which only does ELFv1).

If Clang is used (only on ELFv2), you don't switch to GCC.

You definitely could build FreeBSD without Clang and use external GCC on ELFv2, or use Clang with GNU ld.bfd on ELFv1 (ldd doesn't support ELFv1, in fact Mark Millard played with Clang + ld.bfd on ELFv1), but this is entirely unsupported use-case and I doubt anyone does this anymore (even if someone does, it's unsupported).

There are of course other ports that need to use GCC from ports on powerpc64, because Clang can't compile them (it's still pretty immature on POWER compared to GCC 9 and has some bugs), but it can definitely build OpenJDK.

That's why there's this assumption: that GCC means ELFv1 and Clang means ELFv2.
Comment 13 Mark Millard 2020-01-15 09:53:28 UTC
(In reply to Piotr Kubaj from comment #12)

The case for system-clang's use for powerpc64 is currently
even stronger:

> . . .
> You definitely could build FreeBSD without Clang and use external GCC on ELFv2
> . . .

devel/freebsd-gcc9@powerpc64 (set up to use ELFv2) and
devel/binutils@powerpc64 are, together, not yet sufficient
to buildworld buildkernel . The GNU ld.bfd goes into a
unbounded loop during buildworld; for example, while trying
to link lld together. (I've reported that loop code and its
behavior upstream.)

I've not tried devel/freebsd-gcc6@powerpc64 for ELFv2. But
gcc6 is beyond the gcc folks supporting it at this point.

I hope that at some point at least 2 modern toolchains
support buildworld buildkernel producing working code,
including booting. (I also hope for effective ABI
compatibility.)

system-clang + devel/binutils@powerpc64 produces a kernel
that crashes. (For all I know, both the binutils and the
kernel contribute to the mismatches are at runtime that
lead to the kernel crashing.)
Comment 14 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-15 10:34:40 UTC
(In reply to Mark Millard from comment #13)
So it's reasonable to assume GCC being used on ELFv1 and Clang being used on ELFv2 :)
Comment 15 Greg Lewis freebsd_committer freebsd_triage 2020-01-15 19:20:38 UTC
Ok, let's go ahead then.  Note that there will be an update to 11.0.6 coming through fairly soon, but that shouldn't impact the changes in this PR.
Comment 16 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-15 19:26:19 UTC
Can you upload my bootstrap to MASTER_SITES then?
Comment 17 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-15 19:39:13 UTC
(In reply to Greg Lewis from comment #15)
Also, the existing elfv1 bootstrap needs to be renamed to have -elfv1 suffix.
Comment 18 Greg Lewis freebsd_committer freebsd_triage 2020-01-15 21:27:11 UTC
I've downloaded the bootstrap and put it in the same directory as the others and created a symlink for the elfv1 version.  This usually takes a few hours to be mirrored before a fetch will work.
Comment 19 Piotr Kubaj freebsd_committer freebsd_triage 2020-01-15 22:08:16 UTC
Thanks!
Comment 20 commit-hook freebsd_committer freebsd_triage 2020-01-15 22:08:23 UTC
A commit references this bug:

Author: pkubaj
Date: Wed Jan 15 22:08:05 UTC 2020
New revision: 523182
URL: https://svnweb.freebsd.org/changeset/ports/523182

Log:
  java/openjdk11: add bootstrap and fix compilation for powerpc64 elfv2

  Add bootstrap for powerpc64 elfv2.

  Because of issue with macros in precompiled.hpp, --disable-precompiled-headers is necessary.

  Since openjdk compiles for elfv1 by default on big-endian ppc64, use a patch to compile for elfv2.

  I assume here that GCC will be used exclusively on ELFv1 systems and Clang on ELFv2.

  PR:		243182
  Approved by:	glewis (maintainer)

Changes:
  head/java/bootstrap-openjdk11/Makefile
  head/java/bootstrap-openjdk11/distinfo
  head/java/openjdk11/Makefile
  head/java/openjdk11/files/patch-make_autoconf_flags-cflags.m4