This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[RFC PATCH 0/5] glibc: IEEE Std 754 NaN interlinking support
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: <libc-alpha at sourceware dot org>
- Cc: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Daniel Sanders <Daniel dot Sanders at imgtec dot com>, Leonid Yegoshin <Leonid dot Yegoshin at imgtec dot com>
- Date: Fri, 20 Nov 2015 07:29:22 +0000
- Subject: [RFC PATCH 0/5] glibc: IEEE Std 754 NaN interlinking support
- Authentication-results: sourceware.org; auth=none
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