[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200602021245.GO31009@gate.crashing.org>
Date: Mon, 1 Jun 2020 21:12:45 -0500
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Joseph Myers <joseph@...esourcery.com>
Cc: Daniel Kolesa <daniel@...aforge.org>, libc-alpha@...rceware.org,
eery@...erfox.es, musl@...ts.openwall.com,
Will Springer <skirmisher@...tonmail.com>,
Palmer Dabbelt via binutils <binutils@...rceware.org>,
via libc-dev <libc-dev@...ts.llvm.org>, linuxppc-dev@...ts.ozlabs.org
Subject: Re: ppc64le and 32-bit LE userland compatibility
On Mon, Jun 01, 2020 at 11:45:51PM +0000, Joseph Myers wrote:
> On Tue, 2 Jun 2020, Daniel Kolesa wrote:
> > Are you sure this would be a new port? Glibc already works in this
> > combination, as it seems to me it'd be best if it was just a variant of
> > the existing 32-bit PowerPC port, sharing most conventions besides
> > endianness with the BE port.
>
> The supported glibc ABIs are listed at
> <https://sourceware.org/glibc/wiki/ABIList>.
powerpcle-linux already does work somewhat, and that should also he
worth something, official or not ;-)
(It has worked for very many years already... That is, I have built it
a lot, I have no idea about running a full distro that way).
> > 128-bit IEEE long double would not work, since that relies on VSX being
> > present (gcc will explicitly complain if it's not). I'd be all for using
>
> The minimum supported architecture for powerpc64le (POWER8) has VSX. My
> understanding was that the suggestion was for 32-bit userspace to run
> under powerpc64le kernels running on POWER8 or later, meaning that such a
> 32-bit LE port, and any ABI designed for such a port, can assume VSX is
> available. Or does VSX not work, at the hardware level, for 32-bit
> POWER8? (In which case you could pick another ABI for binary128 argument
> passing and return.)
The current powerpcle-linux runs on anything 6xx, or maybe older. It
isn't actually supported of course.
If the CPU is Power8, that does not mean VSX is available to you.
VSX works fine in 32-bit mode (with the standard gotcha that the GPRs
do not preserve the high part in all cases, so e.g. the m[ft]vsr insns
might not work as you want.
Passing IEEE QP float in GPRs would be natural for most ABIs, and it
should work fine indeed. That isn't currently supported in GCC (needs
some libgcc work), and it might need __int128 to work on 32-bit ports
first.
> > There is also one more thing while we're at this. The 64-bit big endian
> > Void port uses the ELFv2 ABI, even on glibc. This is not officially
> > supported on glibc as far as I can tell, but it does work out of box,
> > without any patching (things in general match little endian then, i.e.
> > ld64.so.2 etc, but they're big endian). Is there any chance of making
> > that support official?
>
> If you want to support ELFv2 for 64-bit big endian in glibc, again that
> should have a unique dynamic linker name, new symbol versions, only
> binary128 long double, etc. - avoid all the legacy aspects of the existing
> ELFv1 port rather than selectively saying that "ELFv1" itself is the only
> legacy aspect and keeping the others (when it's the others that are
> actually more problematic in glibc).
You should view it as a variant of the LE ELFv2 port, it has nothing
much to do with the other BE 64-bit PowerPC ports, other than being BE.
Segher
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
