This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gold on PowerPC checks/merges long double FP ABI tag across shared libraries

On Sat, Dec 14, 2019, at 12:29, Alan Modra wrote:
> On Tue, Dec 10, 2019 at 05:16:03PM +0100, Daniel Kolesa wrote:
> > Hello,
> > 
> > I'm sending this here because I'm not sure how much of an intended
> > behavior this is. 
> > 
> > So, here's the problem: gold on PowerPC (either 32/64/64le) checks
> > and merges the FP ABI tag across shared libraries as well as across
> > regular object files . This is different from what bfd behaves like,
> > which only checks and merges it for actual object files.
> This change from 2001 intending to ignore empty relocatable object
> files,, is
> why the bfd linker ignore shared libraries.  (ELF shared library 
> sections are removed by bfd_section_list_clear at bfd/elflink.c:4244.)
> I think it very likely that it is entirely accidental that shared
> library attributes are ignored by ld.bfd.  This would leave us open to
> linking with ABI incompatible libraries.
> > I suspect that the bfd behavior is correct here - for one, static
> > and shared linking behavior should be the same, and also sometimes
> > you need an external shared library compiled with 128-bit FP ABI and
> > your application with 64-bit FP ABI and know the symbols won't be
> > used.
> Actually, I think the bfd behaviour is a bug.  I agree that it is a
> problem when a shared library provides some FP functions that you
> don't use (and thus might not be extracted from an archive when
> linking).  Conversely, if you do use the functions wrongly, it would
> be nice to be warned as you would if extracting relocatable object
> from an archive.

Well, it does break what is perfectly valid behavior by default - and by making shared libs error, you're introducing behavior that is different from static linking. Of course, it's different either way, because static libs *will* error when you actually do use the affected object file from the archive, while shared libs won't. But also the current gold behavior is a problem because you're basically always linking against libc and glibc *does* support compiling applications with -mlong-double-64 even if the libc itself is tagged with 128-bit.

> > Notable cases include the musl libc, which only supports 64-bit long
> > double, but still needs to be compiled with 128-bit FP
> > ABI in order to include the IBM softfp emulation functions for
> > TFmode; or, glibc supports both 64-bit and 128-bit long double ABI
> > at once and will redirect the symbols depending on what you compile
> > your thing with.
> > 
> > Example:
> > 
> > $ echo "void foo(long double x) {}" > test.c       
> > $ gcc test.c -o -shared -mlong-double-64  
> > $ gcc test.c -o -shared -mlong-double-64 -fuse-ld=gold
> > /bin/ error: /tmp/ccsHdyhv.o uses 64-bit long double, /usr/lib/gcc/powerpc64le-linux-gnu/9.2.0/../../../../lib/ uses 128-bit long double
> > /bin/ error: /tmp/ccsHdyhv.o uses 64-bit long double, /usr/lib/ uses 128-bit long double
> > collect2: error: ld returned 1 exit status
> > $ gcc test.c -o -shared -mlong-double-64 -fuse-ld=gold -static-libgcc
> > /bin/ error: /tmp/cc3AcDER.o uses 64-bit long double, /usr/lib/ uses 128-bit long double
> > collect2: error: ld returned 1 exit status
> You do of course have --no-warn-mismatch to silence to warning.

True, but having to explicitly provide that is problematic. That said, I resolved this for libgcc, by making the bits explicitly compiled with -mlong-double-128 also compile with -mno-gnu-attribute, so only the glibc -mlong-double-64 issue remains.


> -- 
> Alan Modra
> Australia Development Lab, IBM

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]