RFR (M): 8036767 PPC64: Support for little endian execution model

[Volker Simonis]

On Thu, Feb 26, 2015 at 8:58 AM, David Holmes <david.holmes at oracle.com> wrote:
> <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.
>
>
> 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?)

Yes, ARCH/ppc64 is only used by hotspot-only builds. ARCH is
explicitly set to 'uname -m' in hotspot/make/linux/makefiles/defs.make
if it isn't already defined:

# ARCH can be set explicitly in spec.gmk
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

And that's because of 8046471 (we've just discussed that before in the
thread for "8072383: resolve conflicts between open and closed ports"
:)

We still use hotspot-only builds (e.g. for the nightly build of all
the different hotspot repositories but I don't know if that will be
still possible after the big HotSpot make rework (see this thread
http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-December/003339.html).

>
> 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.
>
> 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.
>

That sounds good. I would support this approach.

> 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.
>

Yes, as far as I know "uname -m" returns ppc64le on little endian
machines. But the case of hotspot-only builds which don't have ARCH
defined is anyway handled specially in
hotspot/make/linux/makefiles/defs.make (see the code snipped above). I
think if we would change that to:


# ARCH can be set explicitly in spec.gmk
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 := ppc
  endif
  ifeq ($(ARCH),ppc64)
    ARCH := ppc
  endif
endif

It should be also possible to get rid of the ARCH/ppc64 case and unify
the hotspot-only with the top-level build.

One more observation: the changes in src/os/linux/vm/os_linux.cpp
collide with the changes Dean (put him on CC) has done for 8072383.
Dean's change handles this more general (which is good) but
nevertheless the one who pushes his changes later will have to fix his
patch.

Regards,
Volker

> 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,
>>>
>