GNU attribute output on errors

Carlos O'Donell carlos@redhat.com
Tue Jul 3 15:37:00 GMT 2018


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?

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

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'".

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 :-)

Did I answer your questions?

-- 
Cheers,
Carlos.



More information about the Binutils mailing list