This is the mail archive of the
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: Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 4 May 2001 12:20:57 +0200
- Cc: Andreas Jaeger <aj at suse dot de>, libc-alpha at sources dot redhat dot com, bastian at kde dot org
- References: <firstname.lastname@example.org> <email@example.com>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Fri, May 04, 2001 at 01:02:27AM -0700, David S. Miller 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.
Actually I'm not sure about this statement, unless Uli has real numbers and
real programs which do the preallocation.
I've spent a couple of days 4 months ago on this (have stopped when I run
accross kernel bugs in ELF handling) and I'll try to give it some time in
the near future again.
You get basically all R_*_RELATIVE resolved for free (I have
a program which prelinks ld.so so far) - but if the .got has relative
symbols intermixed with other relocs this saves nothing (otherwise one could
gain a few page COWs).
Then it depends (though I have not gone up to the point where I could do
actual measurements). Basically, on RELA architectures it is simpler and
cheaper than on REL arches.
My plan was that ld.so has a special mode (similar LD_TRADE_LOADED_OBJECTS)
where it would print all conflicts and then there was a special tool which
gathered these conflicts from ld.so and a) adjusted vma stuff (this is
basically what the program I wrote already does) and b) prelinked the other
relocations and noted the conflicts. The conflicts can be noted e.g. as an
undo table (where each record is a RELA with library id). The undo table
could be stored in the programs only, the question is where to put it though
(because unless there is some space left between data and bss, either the
undo table would have to share the same VMA as bss (but be present on the
disk unlike bss - this would violate ELF I think), or the linker would have
to save relocations against bss into some non-ALLOC section (so that the
program could go and adjust those after moving bss) or it would have to do
it the hardway (understand the program and adjust references to bss - very
The fact that ld.so does the conflicts discovery would have the advantage of
not having to duplicate all the dynamic linking logic, which would otherwise
have to be done in the prelinker program.