On Wed, Sep 07, 2011 at 01:46:21PM -0700, Kees Cook wrote: > Hi, > > On Wed, Sep 07, 2011 at 10:37:13PM +0200, Guillem Jover wrote: > > Also I'm not sure now if this has been brought up before, but the > > bindnow option might have noticable startup speed impact depending > > on the amount of symbols and shared objects to resolve and load. > > The other options seem sane in general. > > This is, thankfully, no longer the case now that the linker uses string > hashes for symbol resolution. I could not measure a difference in load > times (any delta seemed lost in the noise) even for giant (firefox, > openoffice.org) applications.
It was my understanding that for iceweasel the biggest cost of starting up is in fact the dynamic linker resolving all the relocations. I currently still see this in libxul.so: Relocation section '.rel.dyn' at offset 0x2b480 contains 180767 entries: Relocation section '.rel.plt' at offset 0x18c578 contains 2853 entries: Not to mention all the other libraries that get linked in. Does anybody know if I set bindnow on an executable that it has effect on all libraries that get loaded, or only on the directly linked libraries? Did you try this after a reboot, or was everything already cached? What behaviour do you get for shared libraries that have undefined symbols? I assume they'll break? Kurt -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
