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