Re: making use of --dynamic-list-cpp-typeinfo
Dirk Mueller <[email protected]> Tue, 19 Sep 2006 23:53:14 +0200
| Newsgroups | gmane.comp.kde.devel.optimize |
|---|---|
| Message-ID | <[email protected]> |
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