RFR (M): 8036767 PPC64: Support for little endian execution model
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Wed Mar 12 07:47:27 UTC 2014
Hi,
> Currently you can only build le variant on ppc64le machine and vice versa.
If you have a repo on a central storage, you can build into the same
directory from several different machines. That's what I do all the time
(except for ppc64le, because I don't have such a machine).
Else, we can remove os and cpu from the path, as it's even less likely
that you do a windows cross build on a linux machine.
Best regards,
Goetz.
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Dienstag, 11. März 2014 23:51
To: Lindenmaier, Goetz; David Holmes; Volker Simonis
Cc: HotSpot Open Source Developers; Alexander Smundak
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model
On 3/11/14 2:34 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> basically this comes down to the setting of BUILDARCH in the
> defs.make file.
> I think it is useful the le-port is built into a directory linux_ppc64le_server (Infix le!!).
> It’s the purpose of this path naming to keep incompatible builds apart.
It would only help if you could do cross compilation to have both build
variants at the same place. Currently you can only build le variant on
ppc64le machine and vice versa. That is why, I think, David asked if we
can control what variant to build.
I would like to see the changes based on Volker suggestion. We can
compare them and decide which way to go.
Thanks,
Vladimir
> Unfortunately BUILDARCH is also used to find the submakefiles, so these
> two extra ones are needed.
>
> But the ppc64le port needs different compiler and linker settings, so there
> is a good reason to have an extra ppc64le.make.
>
> Only the platform_ppc64le file is completely redundant, but that's acceptable I
> would say.
>
> David, this is the complete change to hostpot for this port - there will not be new
> arch subdirectories in the C-code.
>
>
> Please watch out, there are two threads of this because of the mail server
> problems on the weekend.
>
> Best regards,
> Goetz.
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
> Sent: Dienstag, 11. März 2014 09:59
> To: Volker Simonis
> Cc: HotSpot Open Source Developers; Alexander Smundak
> Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model
>
> On 11/03/2014 6:36 PM, Volker Simonis wrote:
>> On Tue, Mar 11, 2014 at 4:29 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> I don't see anything that actually controls what is built. Is it the case
>>> that the new arch value will be reported by uname on the ppc64le system?
>>>
>>> (I cringe seeing a new top-level arch introduced for this.)
>>>
>>
>> I didn't liked this too much as well in my first review and I think we
>> can get along without a new top-level arch (see
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html).
>>
>> But in the end I can live with both approaches (and having two
>> top-level archs probably makes it slightly simpler to support them
>> both in parallel) so I think finally it is up to you which approach we
>> take.
>
> I agree with your initial review. I don't see a LE build as a distinct
> architecture but a variant of ppc64.
>
> Lets see what anyone else has to say.
>
> Thanks,
> David
>
>
>
>
>
>> Regards,
>> Volker
>>
>>> Thanks,
>>> David
>>>
>>>
>>> On 7/03/2014 1:37 PM, Alexander Smundak wrote:
>>>>
>>>> This patch contains the changes to the build files to build JDK on the
>>>> little endian PowerPC64 running Linux, and the changes to the source
>>>> files to support little endian mode.
>>>> This preceding related change
>>>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for the
>>>> ELFv2 ABi used on the little endian PowerPC64.
>>>>
>>>> Please review and test this change. I need a sponsor.
>>>>
>>>> The patch is at:
>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/
>>>>
>>>> Sasha
>>>>
>>>
More information about the hotspot-dev
mailing list