----- Original Message -----
> On 27/02/2015 11:25 AM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> <trimming>
> >> On 26/02/2015 12:31 PM, David Holmes wrote:
> >>> On 26/02/2015 2:57 AM, Andrew Hughes wrote:
> >>>>>>> These are the revised versions of the webrevs:
> >>>>>>>
> >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/
> >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/
> >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/
> >>>>>>>
> >>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK)
> >>>>
> >>>> Ok if I push the jdk and root parts then? I think someone on the Oracle
> >>>> HS team (David?) needs to push the HotSpot bit.
> >>>
> >>> Best to push it all together I think, which I can do through the hs-rt
> >>> forest. But first I need to see where things settled with all this :) I
> >>> was quite confused by some of the initial suggestions. Will try to get
> >>> to this today.
> >
> > Well, I'd push it all myself if there weren't still restrictions on pushing
> > to HotSpot...
> >
> >>
> >> I'm still very confused by these changes and have trouble tracking the
> >> values of the various "arch" related variables. If I follow this right
> >> presently the only distinction between ppc64 and ppc64le is the value of
> >> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the
> >> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64
> >> is either unused or only used by a hotspot-only build?)
> >>
> >> The desired change is that the top-level architecture (VAR_CPU which
> >> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that
> >> for hotspot the only difference is LIBARCH becomes ppc64le. So to
> >> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the
> >> current ppc; and then hotspot's def.make uses that combined with being
> >> lttle-endian to reset the LIBARCH to ppc64le.
> >
> > From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build
> > will get called with ARCH=ppc64le and fail, because make/defs.make will
> > set SRCARCH to x86
>
> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from
> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to
> ppc as per current code. Then BUILDARCH will check LP64 and so become
> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le.
>
Ah, not in 8 where this was tested:
ARCH=$(OPENJDK_TARGET_CPU_LEGACY)
+# ppc64le uses the HotSpot ppc64 build
+ifeq ($(OPENJDK_TARGET_CPU), ppc64le)
+ ARCH=ppc64
+endif
OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this
case.
9 changed this with:
8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH
So it looks like we're going to end up with three different patches for this
issue.
> >> This all seems very convoluted! Why can you not simply check the value
> >> of BUILD_ARCH for ppc64 and then check the endianess to redefine
> >> LIBARCH? That way you don't need to change ARCH as set by
> >> hotspot-spec.gmk.
> >>
> >
> > How is this different to what we are doing?
>
> Because it doesn't require the switcheroo in the hotspot-spec.gmk.in file
>
So yes, it's not needed on 9. ARCH will be passed to HotSpot as ppc there
and then BUILDARCH set to ppc64, then LIBARCH can be changed as:
ifeq ($(LIBARCH), ppc64)
ifeq ($(OPENJDK_TARGET_CPU_ENDIAN), little)
LIBARCH = ppc64le
endif
endif
I don't see this as a huge difference though, and now someone will need to
re-test this.
> > + # Override LIBARCH for ppc64le
> > + ifeq ($(ARCH), ppc64)
> > + ifeq ($(OPENJDK_TARGET_CPU_ENDIAN), little)
> > + LIBARCH = ppc64le
> > + endif
> > + endif
> >
> > Right there; we're checking the endianness to redefine LIBARCH.
>
> Yes but you can do it based on the value of LIBARCH rather than a
> modified ARCH.
Yes, with 8046471 in place. Hardly a huge difference though.
>
> >> Does "uname -m" return ppc64le ? I'm unclear whether either your
> >> proposal or mine actually works correctly for a hotspot-only build. But
> >> maybe we just don't care about builds not done via configure any more.
> >>
> >
> > It does. Different logic is employed for a configure build (which
> > sets various variables, including ARCH, in hotspot-spec.gmk) and
> > a HotSpot-only build which just use makefiles. If ARCH is not set
> > when we get to the HotSpot build, as in the latter, this block
> > in make/linux/makefiles/defs.make is used:
> >
> > ifndef ARCH
> > ARCH := $(shell uname -m)
> > # Fold little endian PowerPC64 into big-endian (if ARCH is set in
> > # hotspot-spec.gmk, this will be done by the configure script).
> > ifeq ($(ARCH),ppc64le)
> > ARCH := ppc64
> > endif
> > endif
> >
> > This was added as part of:
> >
> > 8036767: PPC64: Support for little endian execution model
>
> I don't know if I already had this conversation but it strikes me as
> really bizarre that the PPC64 port uses two different ARCH values
> depending on whether it is a configure-based build or not! ???
>
It's not just that port. Every build either gets ARCH set by
hotspot-spec.gmk (by way of configure) or by uname -m in
make/linux/makefiles/defs.make. This is necessary if you're
going to allow someone to skip configure and just build HotSpot.
If no-one does that any more, then the old stuff that was needed
for 7 builds (no configure) could be culled.
> That aside if ARCH == ppc64 from uname then:
> - SRCARCH = ARCH/ppc64 = ppc
> - BUILDARCH = ppc64
>
> and so the same fix as above would work for this case.
>
It doesn't, as I said. It's ppc64le. So the uname override is necessary.
For consistency, it probably should now be overridden to be ppc, not
ppc64, given the value passed in from configure changed to that in
8046471.
> > so our addition to hotspot-spec.gmk is just to do the same as this
> > block for configure builds.
> >
> > It was unneeded before because configure would just set the arch
> > to ppc64 for the entire build, not just HotSpot.
>
> AFAICS it set it to ppc not ppc64.
I was referring to:
- VAR_CPU=ppc64
+ VAR_CPU=ppc64le
and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH.
>
> David
> -----
>
>
> >> Thanks,
> >> David
> >>
> >>
> >> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why
> >> bother also doing the switcheroo in
> >> <top>/common/autoconf/hotspot-spec.gmk.in when you could just do
> >> everything in hotspot/make/defs
> >>
> >>> David
> >>> -----
> >>>
> >>>
> >>>> Thanks,
> >>>>
> >>
> >
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
