This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Prelinking of shared libraries
- To: "David S. Miller" <davem at redhat dot com>
- Subject: Re: Prelinking of shared libraries
- From: Waldo Bastian <bastian at kde dot org>
- Date: Fri, 4 May 2001 14:21:59 -0700
- Cc: Andreas Jaeger <aj at suse dot de>, libc-alpha at sources dot redhat dot com
- References: <hoae4tvafc.fsf@gee.suse.de> <15090.25107.547554.197469@pizda.ninka.net>
On Friday 04 May 2001 01:02, you wrote:
> Andreas Jaeger writes:
> > I'm currently looking into what needs to be done to implement
> > prelinking in glibc (I'm not volunteering yet ;-) and whether it would
> > really help.
>
> IRIX does prelinking, Uli and others looked into it, and the result
> if I remember correctly is that the added complexity nullified much
> of the performance gain.
I think whether it is worth it pretty much depends on the situation. If you
look at the situation with C programs I don't think it is worth it, but with
C++ libraries that provide baseclasses (Qt) you end up with huge data
sections due to the vtables which basically is a worst-case scenario wrt ELF
cause you have to do all the relocations upfront and you waste a lot of
memory. If e.g. the vtables would redirect through the .got (no idea if that
is possible, I guess that would give undesirable runtime effects) the problem
wouldn't be that big cause then the relocation could be done lazy and you
would have less relocations cause you would have less duplicates.
You see the waste of memory back in C libraries that contain large tables
like const char *[] { "this", "is", "a", "table" }; cause although the data
of the table is shared, the index pointers are being relocated and all end up
in your .data segment. (there is less of a performance issue here, cause
those relocations don't require a symbol lookup)
Cheers,
Waldo
--
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com