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

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

On Sat, 14 Nov 2015, Cary Coutant wrote:

> > 3.3.2 Static Linking Object Acceptance Rules
> >
> >  The static linker shall follow the user selection as to the linking mode
> > used, either of `strict' and `relaxed'.  The selection will be made
> > according to the usual way assumed for the environment used, which may be
> > a command-line option, a property setting, etc.
> >
> >  In the `strict' linking mode both `strict' and `legacy' objects can be
> > linked together.  All shall follow the same legacy-NaN or 2008-NaN ABI, as
> > denoted by the EF_MIPS_NAN2008 flag described in Section 3.1.  The value
> > of the flag shall be the same across all the objects linked together.  The
> > output of a link involving any `strict' objects shall be marked as
> > `strict'.  No `relaxed' objects shall be allowed in the same link.
> >
> >  In the `relaxed' linking mode any `strict', `relaxed' and `legacy'
> > objects can be linked together, regardless of the value of their
> > EF_MIPS_NAN2008 flag.  If the flag has the same value across all objects
> > linked, then the value shall be propagated to the binary produced.  The
> > output shall be marked as `relaxed'.  It is recommended that the linker
> > provides a way to warn the user whenever a `relaxed' link is made of
> > `strict' and `legacy' objects only.
> 
> This paragraph first says that "If the flag has the same value across
> all objects linked, then the value shall be propagated to the binary
> produced", but then says the "output shall be marked as `relaxed'."
> Are you missing an "Otherwise" there?

 The EF_MIPS_NAN2008 flag (if the same across all the objects linked in 
the `relaxed' mode) shall be propagated to the binary produced and the 
output marked as `relaxed'.  If you think this is not clear from the 
wording used, then I can think of rewording the paragraph.  Please note 
however that nowhere across this document the term `flag' is used to refer 
to `relaxed' vs `strict' vs `legacy' annotation, so I'm not really sure 
why this should be ambiguous.

> Early on in the document, you mention "this applies regardless of
> whether it relies on the use of NaN data or IEEE Std 754 arithmetic in
> the first place," yet your solution is only two-state. Wouldn't it be
> better to have a three-state solution where objects that do not in
> fact rely on the NaN representation at all can be marked as "don't
> care"? Such objects could always be mixed with either strict or
> relaxed objects, regardless of linking mode.

 I find it interesting that you raise this point as this was actually 
considered and deferred to investigation at a later stage.

 The reason is we actually have a no-FP annotation already -- in the GNU 
attribute section (propagated these days to the `fp_abi' member of MIPS 
ABI flags by BFD) -- however the encoding is so unfortunate as to make it 
impossible in ELF binary objects to tell apart ones explicitly annotated 
as containing no FP code (typically in compiler-generated code, such as 
made by GCC invoked with the `-mno-float' command-line option) and ones 
with no annotation at all (either legacy compiler-generated code or often 
handcoded assembly sources).  This is because the no-FP annotation is also 
the default value (0) of the attribute in question and is therefore 
removed in processing by BFD rather than being recorded in ELF output.

 It is of course possible to tell corresponding sources apart, however it 
requires a rewrite of parts of attribute handling in BFD so that the 
original annotation is actually unambiguously propagated to an ELF object 
produced by the assembler.  Such a change being considerable enough on its 
own was decided to be made separately, as it can be added later on at any 
time, as an extra case in addition to the two already handled here which 
are required anyway.  This follows the principle of making one step at a 
time.

 There is also a question of a no-FP executable pulling in an FP DSO, 
either at the load time or with dlopen(3): how is such a process supposed 
to be configured -- as `strict' or `relaxed'?  No clear answer has been 
found to this question yet.

 Does this explanation address your concern?

  Maciej