This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Prelinking of shared libraries


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]