GNU attribute output on errors

[Carlos O'Donell]

On 07/03/2018 03:22 AM, Alan Modra wrote:
> .gnu.attributes entries from linker input files are merged to the
> output file, the output having the union of compatible input
> attributes.  Incompatible attributes generally cause a linker error
> and no output.  However in some cases only a warning is emitted, and
> one of the incompatible input attributes is passed on to the output.
> 
> PowerPC tends to emit warnings rather than errors, and the output
> takes the first input attribute.  For example, if we have two input
> files with Tag_GNU_Power_ABI_FP, the first with a value signifying
> "double-precision hard float, IBM long double", the second with a
> value signifying "double-precision hard float, IEEE long double",
> we'll get a warning about incompatible long double types and the
> output will say "double-precision hard float, IBM long double".
> The output attribute of course isn't correct.  It would be correct to
> specify "IBM and IEEE long double", but we don't have a way to
> represent that currently.  While it would be possible to extend the
> encoding, there isn't much gain in doing so.  A shared library
> providing support for both long double types should link against
> objects using either long double type without warning or error.  That
> is what you'd get if such a shared library had no Tag_GNU_Power_ABI_FP
> attribute.
> 
> So this patch provides a way for the backend to omit .gnu.attributes
> tags from the output.

I was around when the .gnu.attributes were created, and back then we had
a long discussion around "don't care" and should have, in my opinion,
encoded this more strongly into the design.

It is a design mistake not to make the encodings more explicit, and the
fact that the POWER backend has emits only warnings is wrong in this case,
since there is an ABI mismatch and it will cause problems.

I suggest IBM pursue adding a value to Tag_GNU_Power_ABI_FP which does
indicate "Don't care" or "Supports either ABI because none of the interfaces
uses long double."

If you instead have two sets of interfaces, one for each of the two 
hardfloat ABI types, then I suggest again you add another value for
"Supports either ABI by virtue of name mangling the interfaces ala C++."

Why? Because as a downstream distribution supporter, for both Fedora 
and RHEL it's a pain to deal with any user errors in this area, and
this will only get more complicated with the float128 changes planned
for POWER.

So while you argue "there isn't much gain..." I would argue that as a
distribution vendor there is a lot of gain. Unless you can explain why
the additional encodings and errors won't help users?

-- 
Cheers,
Carlos.