[RFC PATCH 0/5] glibc: IEEE Std 754 NaN interlinking support

["Maciej W. Rozycki" <macro at imgtec dot com>]

Hi,

 This implements the glibc part of IEEE Std 754 NaN interlinking support, 
as per "MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking" 
<https://dmz-portal.mips.com/wiki/MIPS_ABI_-_NaN_Interlinking>.

 Two design shortcomings have been identified, both applying to a scenario 
where a kernel with interlinking support is used, an `ieee754=relaxed' 
option has been specified to run legacy executables in the relaxed mode, 
and an old `ld.so' binary which has no interlinking support implemented is 
explicitly used to invoke an executable.  In this case the dynamic linker 
is run in the relaxed mode and due to the lack of support for interlinking 
and consequently for the prctl(2) call to switch IEEE Std 754 compliance 
modes the following cases arise:

1. Strict executables are run in the relaxed kernel mode.  Consequently
   IEEE Std 754 Invalid Operation exceptions caused by encountering an 
   sNaN do not trigger a SIGFPE signal where FCSR.Enables.V is set.  As a 
   result alternate exception handling is not available for this case. 

   This does not affect actual interlinking, such old `ld.so' having no 
   interlinking support will enforce the strict mode by always requiring
   the EF_MIPS_NAN2008 ELF file header bits to match, and also rejecting
   relaxed modules due to an unknown `flags2' bit set in the ABI flags
   segment.

   The correct semantics, implemented by new `ld.so' having interlinking 
   support present, is to request the kernel to switch to the strict mode
   and trigger an SIGFPE signal whenever an sNaN is encountered and 
   FCSR.Enables.V is set.

   A similar issue arises where `ld.so' with no interlinking support 
   implemented has been built with new toolchain as a relaxed binary.

2. Legacy executables whose EF_MIPS_NAN2008 ELF file header bit does not 
   match that of `ld.so' are refused to run.  This is because old `ld.so'
   does not interpret the kernel mode passed via AT_FLAGS and always 
   enforces the strict mode.

   The correct semantics, implemented by new `ld.so' having interlinking
   support present, is to ignore EF_MIPS_NAN2008 ELF file header bits and 
   therefore allow both the executable and any other modules to load and 
   run.

 Two potential solutions have been identified to the first issue of the 
two:

1. Move the IEEE bit in MIPS ABI flags to the `flags2' member (swap it 
   with the RELAXED bit).  That would stop legacy `ld.so' accepting 
   strict executables, but also prevent strict executables and DSOs from 
   running on legacy systems though.

2. Make the kernel reject legacy `ld.so' (i.e. any ET_DYN binary which has
   a dynamic segment but no interpreter) run directly in the relaxed mode.

Neither of these seems acceptable due to their shortcomings and side 
effects though.  No solution to the second issue has been identified so 
far.

 I don't see this as a big problem though as the direct `ld.so' invocation 
mode is mainly a developer's tool and is not expected to be used by 
ordinary users in the course of application use.  And there is always the 
solution of upgrading `ld.so' available to one which has interlinking 
support implemented.

 Five patches are included of which 1 is a clean-up, 3 are preparatory 
changes and the final one implements the actual feature.  There is no 
Linux kernel version dependency in these changes, backwards compatible 
semantics is preserved based on AT_FLAGS settings used previously and 
error codes returned from unimplemented prctl(2) requests.

 These changes have passed manual testing with both a legacy Linux kernel 
and one supporting NaN interlinking, using an OS configuration supporting 
both the legacy and the 2008 NaN encoding mode:

1. Exhaustive testing has been run of mixing a strict, relaxed and legacy 
   dynamic executable and a strict, relaxed and legacy `ld.so' binary.  
   The `ieee754=relaxed', `ieee754=strict' and `ieee754=strictest' (same 
   as `strict', except that relaxed executables are always rejected) 
   kernel modes were tested.  Executables were run directly and via 
   `ld.so' invoked explicitly.  Testing covered verifying dynamic load 
   acceptance or rejection as required, verifying the correct NaN encoding
   mode has been selected in CP1.FCSR and verifying that Invalid Operation 
   exceptions are triggered or suppressed with sNaN data are required.

2. Representative testing has been run of running a strict, relaxed and 
   legacy static executable using dlopen(3) to load a strict, relaxed and 
   legacy DSO.  Testing covered verifying DSO acceptance or rejection as 
   required.

3. Representative testing has been run of picking up the right DSOs for
   strict, relaxed and legacy dynamic executables from `ld.so.cache' in a 
   configuration with multiple variants available at a time.

A limited number of cases chosen from the above set for smoke testing has 
been run with an OS configuration supporting the legacy NaN encoding mode 
only.  No full regression testing has been run so far however, although 
this is being arranged.

  Maciej