[musl] Re: ppc64le and 32-bit LE userland compatibility

["Daniel Kolesa" <daniel@octaforge.org>]

On Tue, Jun 2, 2020, at 04:12, Segher Boessenkool wrote:
> 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.

He does have a point with multiarch though - e.g. Debian lets you have all architectures in the same system (with the foreign ones running through binfmt of course) and has individual sysroots for each arch, but dynamic linkers still need to be present in a single location. So, different or not, BE/LE should probably each get its own dynamic linker name (musl solves this nicely by using consistent ld-musl-<archname>so, glibc's naming is fairly arbitrary)

> 
> 
> Segher
>

Daniel