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


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

> 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. I don't think that this will fly; instead, as I
understand pre-linking, you'ld try to assign non-overlapping address
spaces for the most common DSOs.

> 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.

Regards,
Martin


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