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

[Phil Blundell]

On Thu, Jun 04, 2020 at 10:39:30PM +0200, Daniel Kolesa wrote:
> Is there *any* way I can take that would make upstreams of all parts 
> of the toolchain happy? I explicitly don't want to go back to ELFv1. 
> While at it, I'd like to transition to ld64 long double format, to 
> match musl and improve software compatibility, which I feel will raise 
> more objections from IBM side.

Although I don't pretend to understand all the nuances of your port, and 
in particular I have no idea what the thing about "ld64 long double 
format" means, this doesn't sound like a particularly unusual situation.  
If I understand correctly, you are in the position of essentially 
wanting to implement the calling-standard part of the ABI on hardware 
that isn't capable of implementing the full ABI as documented.

If that's the case then, depending on exactly what instructions are
missing, I think your choices are:

1a. Define your own subset of ELFv2 which is interworkable with the full 
ABI at the function call interface but doesn't make all the same 
guarantees about binary compatibility.  That would mean that a binary 
built with your toolchain and conforming to the subset ABI would run on 
any system that implements the full ELFv2 ABI, but the opposite is not 
necessarily true.  There should be no impediment to getting support for 
such an ABI upstream in any part of the GNU toolchain where it's 
required if you can demonstrate that there's a non-trivial userbase for 
it.  The hardest part may be thinking of a name.

1b. Or, if the missing instructions are severe enough that it simply 
isn't possible to have an interworkable implementation, you just need to 
define your own ABI that fits your needs.  You can still borrow as much 
as necessary from ELFv2 but you definitely need to call it something 
else at that point.  All the other comments from 1a above still apply.

2. Implement kernel emulation for the missing instructions.  If they
are seldom used in practice then this might be adequate.  Of course,
binaries that use them intensively will be slow; you'd have to judge
whether this is better or worse than having them not run at all.  If
you do this then you can implement the full ELFv2 ABI; your own
toolchain might still choose not to use the instructions that it knows
are going to be emulated, but at least other binaries will still run
and you can call yourself compatible.

3. Persuade whoever controls the ELFv2 ABI to relax their requirements.
But I assume they didn't make the original decision capriciously so
this might be hard/impossible.  ABI definitions from hardware vendors
are always slightly political and we just have to accept this.

FWIW, we faced a similar situation about 20 years ago when the then-new 
ARM EABI was defined.  This essentially required implementations to 
support the ARMv5T instruction set; the committee that defined the ABI 
took the view that requiring implementations to cater for older 
architectures would be too onerous.  It was entirely possible to 
implement 99% of the EABI on older processors; such implementations 
weren't strictly conforming but they were interworkable enough to be 
useful in practice, and the "almost-EABI" was still significantly
better than what had gone before.

Phil