This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Prelinking of shared libraries
On Friday 04 May 2001 15:45, you wrote:
> > There are two issues of concern: time and memory. In order to get better
> > page sharing you basically must get rid of all relocations.
>
> Why is that? For PIC code, the only inter-DSO relocations remaining
> are those that go through the PLT and the GOT.
You forget about the ones in the .data section (due to vtables) In
libkdeui.so.3.0.0 (Latest KDE CVS) I have 15547 relocations of the type
R_386_32 and 12759 of those refer to qt symbols. Most of those seem to come
out of the .data section.
[ 6] .rel.data REL 0008249c 08249c 01faf8 08 A 2 10 4
[ 7] .rel.ctors REL 000a1f94 0a1f94 000020 08 A 2 12 4
[ 8] .rel.dtors REL 000a1fb4 0a1fb4 000020 08 A 2 13 4
[ 9] .rel.got REL 000a1fd4 0a1fd4 002fc8 08 A 2 14 4
[10] .rel.plt REL 000a4f9c 0a4f9c 009278 08 A 2 c 4
(Compare to libkdecore.so.3.0.0 (latest KDE CVS))
[ 6] .rel.data REL 0004d170 04d170 004ed0 08 A 2 10 4
[ 7] .rel.ctors REL 00052040 052040 000028 08 A 2 12 4
[ 8] .rel.dtors REL 00052068 052068 000028 08 A 2 13 4
[ 9] .rel.got REL 00052090 052090 000f98 08 A 2 14 4
[10] .rel.plt REL 00053028 053028 006818 08 A 2 c 4
(With 1719 entries of type R_386_32, 1197 pointing to libqt)
(Note that my KDE libs are different (newer/larger) than those of Andreas.)
> These make up only a
> small percentage of the complete set of pages that can be shared. In
> your report, I found no indication whether you really have used -fPIC
> on all code.
Yes, we do. libtool takes care of that I believe. A typical compile line
looks like:
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../dcop -I../libltdl -I../kdecore
-I../kdeui
-I../kssl -I/ext/cvs/qt-copy/include -I/usr/X11R6/include
-I/ext/kde-head/include -D_REENTRANT -g -ansi -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -Wbad-function-cast -Wcast-align -Wundef -Wconversion
-fno-exceptions -fno-check-new -Wall -pedantic -W -Wpointer-arith
-Wmissing-prototypes -Wwrite-strings -Wno-long-long -Wnon-virtual-dtor
-fno-builtin -frtti -ftemplate-depth-99 -DQT_NO_TRANSLATION
-DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -Wp,-MD,.deps/kapp.pp
-c kapp.cpp -fPIC -DPIC -o .libs/kapp.o
> As Geoff explains, indicating the gcc and as version
> would also help (sorry, I don't know what assembler SuSE has been
> using to build kdecore.so).
This is what I use:
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
GNU ld version 2.10.91 (with BFD 2.10.0.33)
GNU assembler version 2.10.91 (i486-suse-linux) using BFD version 2.10.0.33
> > The idea would be to do the prelinking as if you were linking an actual
> > application and then store the result for later reuse. When you are about
> > to link an actual application you would first try to see if you can use
> > the result of prelinking.
>
> It seems that you propose keeping a separate copy of each DSO for use
> in each application.
No. What currently happens is that the .text and .plt of a lib are shared
between processes but that each process has its own .got and .data.
What I would like to see is that the .got and .data of such a lib would be
shared between the processes (and the various applications) as well.
> I don't think that this will fly;
Well, I can see some difficulties but no fundamental problems.
> instead, as I
> understand pre-linking, you'ld try to assign non-overlapping address
> spaces for the most common DSOs.
Yes that too. That would take care of the relocations that don't depend on
symbols in other libs. But as I try to make clear above, it are the
relocations that _do_ depend on other libs that make the most problems.
In order to get better page sharing you will have to address both issues.
If you only take the relocations that don't depend on symbols, you will have
to make sure that the different type of entries are grouped so that you have
a whole page with only R_386_RELATIVE that you can share. But looking at the
numbers, you will have a hard time filling even a single page, so that is
unlikely to lead to any significant improvement. Besides I doubt whether you
have enough control over the layout of the .data section to pull that off.
(I believe I looked into this with Andreas Schwab about a year ago, by
changing the base address of the library when it was build, but since we
couldn't notice any difference we dropped it.)
> > The prelinking could then be done just like ldconfig currently updates
> > the ld.so.cache and the prelink results could be stored either seperately
> > in the file system, or maybe as an additional ELF section in the library.
>
> Is that even necessary? AFAIK, the sh_addr field of a section is
> exactly there to support pre-linking.
Even better :-)
Cheers,
Waldo
--
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com