This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

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) 

 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]