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. > > Phil > Daniel
