On Thu, 30 Jun 2016, Faraz Shahbazker wrote: > The user-mode patch hasn't gone upstream either, so it is open to > modification. Assuming the kernel currently has no other means of > publishing RIXI support, or there is no existing software relying on > such publication, then a RIXI bit in HWCAP seems appropriate. I think it depends on whether you advertise a fixed hardware feature or a software feature. For NaN interlinking it is obviously a plain software feature set on a program by program basis, and you can have either mode set depending on the kernel command line and main executable's ELF header flags, irrespectively of what hardware supports. So FLAGS was the natural choice, barring the invention of a new vector entry, and HWCAP was out of question. With HWCAP I'd only advertise fixed features, unchanged from the bootstrap till the shutdown (or crash ;) ), and global to the whole system. > @Matthew/@Maciej: If this is a priority, could we swap the libc-abi > numbers for IFUNC(4) and non-exec stack(5) to push this change through > before IFUNC? I think that is the only reason we've held the user-mode > patches for glibc and gcc. A binutils patch with abiversion=5 was > committed, so it will need fixing, but its only a one-liner. TBH I think ABI versions need to be changed incrementally or otherwise we get a broken run-time environment. E.g. if we used version 4 for IFUNC support now, then non-exec stack binaries marked with version 5 would be considered as supporting IFUNC, while in fact they may not, depending on what binutils version they have been built with. So now we need to use 6 for IFUNC anyway as people may have distributed binaries with version 5 recorded already, which obviously do not support IFUNC as it hasn't been upstreamed yet. I'd rather we didn't have this hole, but we can't change history and I just hope we won't go out of range with `e_ident[EI_ABIVERSION]', which is a byte only, anytime soon. NB from the ELF specification it looks to me like this field has been selected for recording ELF binary features in error, where `e_version' should have. This is because the former specifies the ELF *header* version (i.e. changes to the `ElfXX_Ehdr' structure itself, presumably except from `e_ident' itself or at least its first 7 bytes) while it's `e_version' that was meant for the version of the ELF object file (i.e. everything beyond the header). They just both happened to be set to EV_CURRENT or 1 in the original SVR4 ELF gABI, which may have confused someone. To say nothing of `e_version' being 32-bit, providing much more room for manoeuvre. But again, we can't change history and undo the bad choice. Maciej
