Re: GNU attribute output on errors

[Carlos O'Donell <carlos at redhat dot com>]

On 07/03/2018 09:10 PM, Alan Modra wrote:
> 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.

This is where I think we disagree.

My opinion is that you should never omit Tag_GNU_Power_ABI_FP.

It has to be present to distinguish between:

* Don't know? (Old toolchain, no tags).

* Don't care (New toolchain, doesn't matter or both ABIs supported).

The point is to be able to warn on the "Don't know" case so users can
legitimately see and know which objects need to be recompiled in order to
better diagnose ABI issues.

Such old objects do exist, or they might be written in assembly, and just
need to be analyzed and have markup added.

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

I agree completely. I'm only interested in practical problems like those
we will face with two common and in-use float types in the next generation
of distributions, particularly as IBM Advanced Toolchain ships with long-double
support for float128.

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

... and shouldn't be. You are loosing information that could be used to warn
users that they have old objects, or objects that have somehow lost their markup
(been through an aggressive objcopy perhaps).

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

Sure, and if that's what's needed for glibc or libstdc++ then we can use that
there to assemble a "super-object" that has both implementations. However, every
one else up the stack isn't going to build their software that way. They are goin
to use a generic build system and assemble things using the default toolchain
options. So when upstream switches to float128 as the default for long double,
then we're going to start seeing the transition pain at the distribution level.

-- 
Cheers,
Carlos.