GNU attribute output on errors
Alan Modra
amodra@gmail.com
Wed Jul 4 01:10:00 GMT 2018
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
More information about the Binutils
mailing list