[musl] Re: ppc64le and 32-bit LE userland compatibility
Thu Jun 4 22:06:41 GMT 2020
On Thu, Jun 4, 2020, at 23:55, Phil Blundell wrote:
> 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.
Well, the ld64 part is a separate issue. Defining a new long double ABI would break the ELFv2 ABI, since ELFv2 says long double must be 16-byte, of either IBM double-double format or IEEE754 binary128 :)
However, when I was talking about ELFv2 on 970 being a subset, I meant with the IBM double-double format, which has been present since glibc 2.4 at least, and doesn't require any vector functionality (it works even on 32-bit PowerPC)
So, defining a new long double ABI would indeed be a change compared to standard ELFv2. But, if we were doing a new port anyway, I think it'd be potentially worth it.
> 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.
Yes, this is the approach I would like to take.
> 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.
IBM has their commercial interests here and I don't think it'd be wise to take this kind of path. Implementing a new variant would probably be better; if we were documenting such differences, it'd probably be worthwhile to sync up with musl, since it'd be exactly the same ABI.
> 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.
More information about the Libc-alpha