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