PR25882, .gnu.attributes are not checked for shared libraries

[H.J. Lu]

On Fri, May 1, 2020 at 8:28 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Fri, May 01, 2020 at 04:48:38PM -0700, H.J. Lu wrote:
> > On Fri, May 1, 2020 at 4:22 PM Joseph Myers <joseph@codesourcery.com> wrote:
> > >
> > > This binutils patch breaks glibc "make check" for big-endian powerpc
> > > (32-bit and 64-bit).
> > >
> > > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html
> > >
> > > Errors of the form:
> > >
> > > /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double
>
> Hmm, is the Tag_GNU_Power_ABI_FP claim of ibm long double strictly
> correct?  Doesn't libm also support 64-bit long double too?  In which
> case libm ought to be silent about long double support.
>
> That of course can be accomplished by compiling all the object files
> going into libm.so that provide long double functions (or call such
> functions) with -mno-gnu-attributes.  Another method with slightly
> more finesse is to compile all files with the default -mgnu-attributes
> but link with --no-warn-mismatch.  That way the linker will not give
> an error and also not emit the particular Tag with a conflict.  (This
> method assumes that assembly files emit the correct tags.)
>
> > > I don't know whether this is a problem with binutils, or it indicates that
> > > BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE
> > > does to avoid such errors.
> >
> > It is odd to check .gnu.attributes on shared libraries since shared libraries
> > used at link-time can be very different from run-time.
>
> You can say the same about many properties of shared libraries.
> ld.gold on both arm and powerpc does check these attributes for shared
> libraries.  And it's necessary to use ld.gold to link split-stack and
> non-split-stack object files if you want to ensure the non-split-stack
> functions are called with something like the normal stack allocation.
> If you use ld.bfd then non-split-stack functions might be called with
> very small stacks.  So arm and powerpc have a history of checking
> shared library .gnu.attributes.
>
> >  Checking .gnu.attributes
> > on shared libraries gives you very little.
>
> Checking .gnu.attributes protects the user from linking against a
> shared library that say, provides ibm long double math function when
> the user is compiling for ieee long double.  That was the idea behind
> the binutils patch.  There are of course some negatives, chief of
> which is that .gnu.attributes is nowhere near fine enough grained to
> work well with libraries that provide multiple areas of support.  You
> may hit a link error regarding functions you do not use in your app.
>

I don't think checking .gnu.attributes in shared libraries at link-time
can protect shared libraries with different long double math functions
at run-time.  That is the main reason why I introduced .note.gnu.property
section.

-- 
H.J.