making use of --dynamic-list-cpp-typeinfo
Dirk Mueller
mueller at kde.org
Tue Sep 19 23:53:14 CEST 2006
On Tuesday, 19. September 2006 19:10, Lubos Lunak wrote:
> Is there some usable documentation on what exactly this does? I don't
> quite see what symbols are affected from the posts on the binutils mailing
> list I could find.
It affects all function symbol relocations. on x86, this is usually R_386_32
or R_386_JUMP_SLOT. What it does is that whenever e.g. the code in libqt3
calls QString::length(), it doesn't do so via the normal symbol based ELF
lookup semantics (which would possibly allow to override a symbol via
LD_PRELOAD or similiar), but binds all internal references directly. This
means that it converts symbol based relocations (which are slow due to the
hash table and the final string collision check) into plain relative
relocations (which are pretty fast as they're just a memory add). Plain
relative relocations are also easy to get rid of via prelink or other
methods. In my test however there were not only much less symbol based
relocations, there were also less relocations overall. I'm not sure why that
is the case, but apparently the linker can get rid of some relocations
completely. I'm not sure which.
Of course this breaks stuff like rtti, dynamic_casts or exception handling
accross shared lib boundaries (which is broken for us anyway because we use
local binding in dlopen by default). But a fix for that was done in binutils
in a way that it automatically excludes typeinfo from internal binding, so it
should theoretically be transparent, even though it doesn't matter for us
anyway.
The only thing that stops working is when we intercept a symbol in e.g. libqt,
but I haven't hit that in my test installation. I didn't build all of KDE
with it yet though.
Of course it depends mostly on distributors work, because the flag is only
fully effective when applied to all depending libraries.
Dirk
More information about the Kde-optimize
mailing list