Re: Prelinking of shared libraries

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, May 04, 2001 at 11:23:25PM +0200, Martin v. Loewis wrote:
> > So what relocations can benefit from this?  Let's look at i386 and
> > take libkdecore.so as an example, other architectures should be
> > similar.
> 
> How did you get these data? Looking at libkdecore.so.2.0.0, as
> distributed with SuSE 7.0 (klibs-1.1.2-160), I get
> 
> [ 6] .rel.data         REL             00013898 013898 001a50 08   A  2  10  4
> [ 7] .rel.eh_frame     REL             000152e8 0152e8 002570 08   A  2  11  4
> [ 8] .rel.gcc_except_t REL             00017858 017858 00b2b0 08   A  2  12  4
> [ 9] .rel.got          REL             00022b08 022b08 0005c8 08   A  2  15  4
> [10] .rel.plt          REL             000230d0 0230d0 0016a0 08   A  2   c  4
> 
> Classifying the individual relocations, I get
> 
> R_386_RELATIVE: 7219
> R_386_32:        539
> R_386_GLOB_DAT:  185
> R_386_JUMP_SLOT: 724
> 
> > So out of 4078 relocations we could get rid of 793 - and only of the
> > cheapest relocations.  
> 
> In summary, I find that out of 8667 relocations, prelinking the
> R_386_RELATIVE ones would save 7219.
> 
> That raises two questions: Why do we get different numbers for the
> same shared library? And why do I have so many R_386_RELATIVE
> relocations when the code should be PIC?
> 
> It turns out that most of those relocations are in the .eh_frame and
> the .gcc_except_table, so this looks more like a GCC question: Is it
> that those tables are not position-independent? If so, C++ programs
> would suffer more than C programs.
> 
> Furthermore, I don't understand how pre-linking would proceed. It
> appears that all you had to do is to define a VMA, and relocate a
> certain section to that VMA (updating the sections sh_addr, and the
> relocation entries appropriately). Then, the dynamic linker should
> attempt to map that section to this VMA; if that succeeds, no
> relocations need to be applied. Is that possible? If so, where does
> the added complexity that nullifies the performance gain come from?

Actually there are several more things to update on VMA update.
But anyway, the added complexity is when you prelink all relocations, not
just the RELATIVE ones (but the gains are biggest then).
This is because
a) one has to handle conflicts (ie. when although dynamically linking shared
library against its dependencies would result in relocation X being
relocated to dso Y/address Z, when this library is used either by some other
library or by the main program, the symbol is overridden somewhere and so
you have to relocate it to dso U/address V)
b) if for some reason you don't manage to map the shared library at the
address which was given to the shared library (or you dlopen the library),
then you have to somehow undo the prelinking (on RELA arches this is not
that costly, basically unless it is a PLT slot, you resolve it as you'd
normally would, if it is PLT slot, you either restore the PLT slot to its
default state or resolve it; but on REL unless you have some kind of undo
data this may mean looking up symbol twice (each time with different search
rules)).

	Jakub