This is the mail archive of the 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 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 (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	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	000a1fd4 0a1fd4 002fc8 08   A   2  14 4  
[10] .rel.plt	REL	000a4f9c 0a4f9c 009278 08   A   2   c 4

(Compare to (latest KDE CVS))
[ 6]	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	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../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 
-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

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
GNU assembler version 2.10.91 (i486-suse-linux) using BFD version

> > 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 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 :-)

-- | SuSE Labs KDE Developer |

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