Hi Maciej, Slow thread, sorry for dragging it out further... Maciej Rozycki <Maciej.Rozycki@xxxxxxxxxx> writes: > 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 Am I right in thinking unneeded is not the same as no-float, it has floating point in it but explicitly does not care about NaN encodings because it was built with an option that said so? > -- at compilation/assembly and: > > A. Strict -- enforcing matching NaN encodings -- built from strict, > unknown and unneeded objects of the matching NaN encoding, Must have at least one strict object? > > 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. I'm not entirely sure why 3 or C should care about nan encoding at all because they should be totally independent of the concept. I.e. link any combination, choose a NaN encoding for the resulting object at random but disregard the NaN encoding coming from an unneeded object when combining with others. > 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. The dynamic linker already does a scan of all loaded objects for the purpose of FPXX mode calculations so I doubt it would cost much to recalculate each time a module is loaded. You only need to handle it at load time though not unload. > 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), Seems fine. > however > distributed software compiled as 3 and consequently linked as C, with Not sure about this. Knowing that something does not care about NaN encodings is just as hard as knowing something does care. Getting the different build settings used for default user-builds and distribution packages is also likely to be painful. I think you could safely get away with just building as 2 for everything unless it is known to need matching NaNs, i.e. strict. > 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. The new set of states look good. I think unneeded is the least likely to be used in reality but it would form a basis for nofloat. Thanks, Matthew > Maciej
