> On Tue, 20 May 2014, Jan Hubicka wrote:
>
> > Hi,
> > as disucssed some time ago, our assumption that every symbol of shared
> > library can
> > be interposed at runtime is expensive and prevents a lot of useful
> > optimizations,
> > including inlining or IPA propagation.
> >
> > While this is useful feature, it is rather incommon to use it for bigger C++
> > projects, like firefox and at least clang seems to ignore the ELF
> > interposition
> > rules and always inline/propagate. This patch adds flag to control the
> > behaviour.
> > Symbols explicitly delcared WEAK are still considered as interposable.
>
> I could see a use for an option listing the symbols that can be
> interposed. (For example, glibc supports interposition of a limited
> number of malloc-related symbols, but if it were made to support building
> with LTO in future that it would make sense to be able to optimize calls
> to most other functions.)
I tought glibc uses handcoded local aliases for all its exported symbols except
for those where interposition is allowed.
But yes, this mechanism does kind of similar thing - in addition to enabling
optimizations
ipa.c knows how to create local aliases for those symbols. Compiling:
$ cat ~/t.c
__attribute__
((noinline))
t()
{
printf ("test\n");
}
q()
{
t();
}
$ ./xgcc -B ./ -O2 ~/t.c -fno-semantic-interposition -S -fPIC
will get you:
.set t.localalias.0,t
.globl q
.type q, @function
q:
xorl %eax, %eax
jmp t.localalias.0
which is sort of what many libraries does by hand.
I wonder if this can't be best modeled as yet another visibility setting. I.e.
having visibility=default with
interposition assumed and visibility=default-no-semantic-interposition with
visibility not allowed.
This can be both for -fvisibility flag and for attributes?
Honza
>
> --
> Joseph S. Myers
> [email protected]
