bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Undefined use of weak symbols in gnulib


From: Michael Matz
Subject: Re: Undefined use of weak symbols in gnulib
Date: Wed, 28 Apr 2021 13:15:09 +0000 (UTC)
User-agent: Alpine 2.20 (LSU 67 2015-01-07)

Hello,

On Wed, 28 Apr 2021, Florian Weimer via Binutils wrote:

> > commit 954b63d4c8645f86e40c7ef6c6d60acd2bf019de
> > Author: Alan Modra <amodra@gmail.com>
> > Date:   Wed Apr 19 01:26:57 2017 +0930
> >
> >     Implement -z dynamic-undefined-weak
> >
> >     -z nodynamic-undefined-weak is only implemented for x86.  (The sparc
> >     backend has some support code but doesn't enable the option by
> >     including ld/emulparams/dynamic_undefined_weak.sh, and since the
> >     support looks like it may be broken I haven't enabled it.)  This patch
> >     adds the complementary -z dynamic-undefined-weak, extends both options
> >     to affect building of shared libraries as well as executables, and
> >     adds support for the option on powerpc.
> 
> I'm not sure if this option is compatible with all compilers on POWER.
> 
> The old binutils behavior allowed the compiler to optimize this common
> pattern
> 
> void f1 (void) __attribute__ ((weak));
> 
> void
> f2 (void)
> {
>   if (f1 != 0)
>     f1 ();
> }
> 
> into an unconditional call to f1 because the linker would replace the
> call with a NOP if the symbol is undefined, reproducing the effect of
> the if condition.  However, GCC 10 does not appear to perform this
> optimization on powerpc64le.

GCC assumes addresses of functions to be non-null, _except when declared 
weak_.  Over the years we fixed problem in that aspect always into that 
direction (hence the above testcase should always be emitted with an 
actual test, otherwise it would be considered a bug worth fixing).  That 
would be consistent with making undefined weak symbols dynamic in the ELF 
case, so that the ultimate test survives until runtime.

I don't know what other compilers are doing, of course.


Ciao,
Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]