[RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
Maciej W. Rozycki
macro@imgtec.com
Thu Aug 24 15:35:00 GMT 2017
Hi Matthew,
On Fri, 11 Nov 2016, Matthew Fortune wrote:
> This means that a user consciously creating an object that 'needs' ieee
> compliance via use of -fieee=strict or -mieee=strict is thwarted by the
> next user who builds the executable. This kind of scenario can occur with
> a static library prepared by an expert in floating point and then someone
> casually including that into a bigger application. Obviously a similar
> issue is present with the rules around executable and shared libraries
> where the executable's compliance mode can override a shared library
> but at this level we are not losing any information and the executable
> has either very specifically been set to 'relaxed' mode or the kernel
> has set legacy to mean relaxed. The latter can at least be fixed by
> changing the kernel. Losing information in a static link cannot be
> fixed.
I think I can see your point and I admit I may have oversimplified the
model, losing a piece of crucial information and consequently control.
What I can propose is a changed model which requires three states at
compilation/assembly, and then four states at link/load time automatically
determined by the input objects, with a possible influence of linker
command-line options to prevent certain transitions. These are (names up
to discussion):
1. Strict -- known to require the NaN encodings to match,
2. Unknown -- may or may not require the NaN encodings to match,
3. Unneeded -- known not to require the NaN encodings to match
-- at compilation/assembly and:
A. Strict -- enforcing matching NaN encodings -- built from strict,
unknown and unneeded objects of the matching NaN encoding,
B. Unknown -- matching the NaN encodings, but not enforcing it -- built
from unknown and unneeded objects of the matching NaN encoding,
C. Unneeded -- not requiring the NaN encodings to match -- built from only
unneeded objects of the matching NaN encoding,
D. Relaxed -- known not to match either NaN encoding -- built from unknown
and unneeded objects of which at least one does not match the NaN
encoding of the remaining objects, or from at least one relaxed object.
-- at link/load time. Any other object combinations would result in a
link/load failure, e.g. you could not mix A with a D object, or any object
not matching the NaN encoding.
The difference between B and C is at the run time -- the treatment of B
is controlled by the "ieee754=" kernel option, whereas C always ignores
NaN compatibility of the hardware. The difference between C and D is at
the link/load time -- C can be upgraded to A or B, but D is inherently
lost and remains at D. At the ELF binary level B objects correspond to
what I previously referred to as legacy objects, i.e. no extra annotation
beyond the EF_MIPS_NAN2008 bit. There could be a linker command-line
option to prevent a transition from B to D from happening if not desired,
causing a link failure.
The states would be maintained at run-time, when a DSO is dlopen(3)ed.
A would accept A, B or C if matching the NaN encoding, and stay at A. B
would accept B or C if matching the NaN encoding, and stay at B. With the
relaxed kernel configuration B would also accept B or C using the opposite
NaN encoding or D, and switch to D. C would accept C if matching the NaN
encoding, and stay at C. C would accept B if matching the NaN encoding,
and switch to B. C would accept B or C using the opposite NaN encoding or
D, and switch to D. Any other combinations would cause a dlopen(3)
failure.
In this model only the initial state is determined by the main executable
and further transitions are possible as dynamic objects are added, making
the use of prctl(3) to switch states more prominent. One unfortunate
consequence is that dlopen(3)ing an A DSO from a B or C executable
switches its state to A permanently making it impossible to subsequently
dlopen(3) a D DSO even though it would have be allowed beforehand.
Perhaps it would be possible to track state transitions and restore the B
or C state as appropriate when the A DSO is dlclose(3)d. Likewise with B
or C to D and C to B state transitions.
In this model I think I would recommend distributions to have the
compiler configured for 2 by default, so that user-built software comes
out as B (with a link-time transition to D disallowed by default), however
distributed software compiled as 3 and consequently linked as C, with any
pieces identified as doing proper math compiled as 1 and consequently
linked as A, for both NaN encodings if required. The reason is I think we
need to draw a line somewhere and conclude that while we can try to
minimise the damage caused by the hardware peculiarities created by the
architecture maintainers we cannot prevent all cases of bad software
builds caused by gross incompetence.
Does this model match your expectations? If so, then I'll work on a
specification update and a corresponding user interface change, and post
the results.
Maciej
More information about the Binutils
mailing list