Em ter 20 maio 2014 22:04:32 você escreveu:
> 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.
>
> Bootstrapped/regtested x86_64-linux, will commit it tomorrow if there are
> no complains. (Feedback is welcome!)
This patch seems to be controlling the behaviour of the compiler when seeing
functions global that may or may not be interposed in the future. There
doesn't seem to be a correct way to declare "no, this can't be interposed". Is
there any plan of doing that?
In other words, if a function is not declared inline and GCC decides not to
inline it anyway, then it and the linker will generate an indirect call
through the PLT, with an associated (lazy) relocation. It's worse for
variables: all non-hidden global variables must always be accessed indirectly
via the GOT.
We have a couple of solutions for forbidding interposing (-Bsymbolic and
protected visibility) and thus improve code generation, but they seem to
always cause trouble in some places. The most common one for variables is copy
relocation, whereas for functions it's the official function pointer address
(will resolve to the PLT in the main executable).
Large projects would really appreciate being able to declare some symbols not
interposable at all.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
