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

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, Jun 05, 2020 at 11:59:32PM +0200, Daniel Kolesa wrote:
> On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote:
> > > Third party precompiled stuff doesn't really need to concern us, since none really exists.
> > 
> > ... Yet.  And if you claim you support ELFv2, not mentioning the ways
> > your implementation deviates from it, users will be unhappy.
> 
> Will they?

Yes; not only *your* users, but also users of the "actual" ELFv2 (for
BE), if anything starts using that: the ABI is defined, and at least at
some point it worked, it is not unreasonable to think someone might
want to start using it).

Just don't pretend X and Y are the same if they are not, people do not
like to be misled.  Just be clear upfront what the differences are, and
everyone will be happy.  Confusing people and wasting their time won't
make you very popular though ;-)

> The system explicitly mentions that the minimum target in the binary packages is 970. Users can't be expecting features that the hardware we support doesn't support :)

But you are not the only user of ELFv2.

> Also, we're not the only ones that do this - there's musl of course, but there's also the BSDs. FreeBSD 13 uses ELFv2, and supports all the old hardware including processors without VMX, let alone VSX. OpenBSD is likely to take the same path. But I'm not opposed to making this explicit, if that's what it takes to make other people happy with it.

Yeah, please do :-)

> > > It's also still an upgrade over ELFv1 regardless (I mean, the same things apply there).
> > 
> > Yeah, in mostly minor ways, but it all adds up for sure.
> 
> It's made my life simpler on numerous occasions,

Great to hear that!

> and allowed us to bring in software that'd otherwise take significant patching (no software is complete until it has its own assembly implementation of coroutines or something like that :P),

.. but does it have a mail client?

> > That depends on what you call the average case.  Code that is control
> > and memory-bound will not benefit much from *anything* :-)
> 
> Average case is, quite literally, an average case - i.e. the average of all the software packages shipped in a distro :)

Ah, mostly boring stuff :-)

> > Yeah, but it helps quite a bit if your system (shared) libraries get all
> > improvements they can as well.
> 
> Well, glibc will still benefit automatically to a degree even if not built for a modern baseline, since it has runtime checks in place already; as for other things... well, at least for Void, I already mentioned before we're as much of a source distro as a binary one - people can easily rebuild things that bottleneck them, with modern CFLAGS, and still have things be interoperable.

Yeah, good point there.

> > I'm not trying to dissuade you from not requiring VSX and 2.07 -- this
> > sounds like your best option, given the constraints.  I'm just saying
> > the cost is not trivial (even ignoring the ABI divergence).
> 
> Of course the cost is there - it's just not something I can do anything about. I generally recommend that people who can run LE should run LE. We're a bi-endian distribution, so there is a complete, fully functional, ISA-2.07-baseline ppc64le variant (in fact, it's our best-supported port, with greatest repo coverage and testing), as well as the 970-targeting ppc64 variant.

Ah, so your BE target is mostly for legacy hardware?  That took a while
to sink in, sorry!  :-)

> I know about the biarch case as well, and there is also multilib, as an even more elaborate form of that. That's not directly related to what I originally said, though

Biarch is why -m32 and -m64 can work at all (for building user binaries).
My point is that this does *not* work for most finer ABI (or OS) -related
points -- you really do need a toolchain built specifically for that
config.


Segher