GNU attribute output on errors

[Alan Modra]

On Tue, Jul 03, 2018 at 11:37:02AM -0400, Carlos O'Donell wrote:
> On 07/03/2018 09:44 AM, Alan Modra wrote:
> > 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.
> 
> You mean this:
> 
> include/elf/ppc.h:
> 232   /* FP ABI, low 2 bits:
> 233      1 for double precision hard-float,
> 234      2 for soft-float,
> 235      3 for single precision hard-float.
> 236      0 for not tagged or not using any ABIs affected by the differences.
> 237      Next 2 bits:
> 238      1 for ibm long double
> 239      2 for 64-bit long double
> 240      3 for IEEE long double.
> 241      0 for not tagged or not using any ABIs affected by the differences.  */
> 242   Tag_GNU_Power_ABI_FP = 4,
> 
> So low 2 bits 00 mean not-tagged, so supports any interface.
> 
> That seems great. Does anyone use this today?

Not the low two bits since they imply the high two bits are also zero
and therefore Tag_GNU_Power_ABI_FP is omitted.  The next two bits
being zero is used.

> >> 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.
> 
> How is this a mythical ABI safety issue?

I meant in the sense of an ideal.  Not all cases of potential ABI
breakage are caught by the tags.

> We are about to transition to float128 for long double on POWER, particularly
> for POWER9 hardware support.
> 
> There will be a period where lots of users mix these things up and have real
> ABI issues, both on Fedora and in future RHEL.
> 
> Are you saying this won't be a problem? How do you plan to prevent the problem?
> 
> This was a constant issue on ARM when we added hard-float, and it took
> years for people to sort out toolchains in one of either direction e.g. all
> hard-float or all soft-float. The error in that case we incredibly useful in
> preventing problems.
> 
> The only people whom I know that are building libraries to support multiple
> floating point formats are glibc and libstdc++, and we can certainly do the
> work required to produce such libraries. Why wouldn't these libraries use
> some macro with an asm that injects the required markup to mean "not-tagged"
> because they support both types?
> 
> Everyone else up the stack is either going to use one or the other float format
> whichever is the default generated by the system toolchain.
> 
> > 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?
> 
> Given that you have "not-tagged" that would be sufficient, since the semantics
> of the symbol mangling, in this case, imply the ABI.
> 
> My point is that this is not "no tag", but rather "tagged as 'don't care'".

Which is treated *exactly* the same as no tag.

> We need a way for application authors to markup their sources to overrides the
> tag by providing their own tag, and that's OK. Few developers will do this and
> those that do will know what they are doing.
> 
> And you should switch from warnings to errors for ABI incompatibility because
> downstream distributions will thank you :-)

OK, I do think we can do that in time for 2.31.  I'd forgotten that I
added -mno-gnu-attribute to powerpc gcc some time ago, so combining
incompatible objects isn't too difficult.

-- 
Alan Modra
Australia Development Lab, IBM