GNU attribute output on errors

[Alan Modra]

On Tue, Jul 03, 2018 at 08:27:26AM -0400, Carlos O'Donell wrote:
> 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."

We already have that.

> 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?

Perhaps a PowerPC linker error might be better in most cases, but we'd
need a way to circumvent that when you really do want to combine
"incompatible" object files, for example to produce a shared library
that supports multiple long double formats.  One way of course would
be "objcopy -R .gnu.attributes" for each object linked into the
library, but that's annoying.  I don't believe in annoying users too
much in pursuit of a mythical ABI safety.

As for extra encodings, I'd say the onus is on you to explain how
they will help users.  What exactly should the linker do with a shared
library tagged with "supports IBM long double and IEEE long double"?
How would that differ from linking against a shared library without
info about long double?

-- 
Alan Modra
Australia Development Lab, IBM