On Fri, Nov 22, 2002 at 03:18:28PM +0900, Bang Jun-Young wrote:
> Hi folks,
> 
> Here's the summary of what I have been thinking about ELF prebinding
> since a couple times of objections from people against my previous
> not-good implementation ;-):
> 
> - Every binary, including executable and shared object, has .csum
>   section inserted by ld(1) at compile time. It is 32-bit long and
>   used for storing checksum (CRC32) of the binary.
> 
> - Actual prebinding and prerelocation is done by ld.elf_so(1). After 
>   ld.elf_so(1) loads a binary for the first time, it creates a disk
>   file in /usr/libexec/reloc (say it "cache") and writes all of the
>   relocated GOT and PLT sections in memory to the file (checksum and
>   other necessary information as well). In any subsequent execution
>   of the same binary, ld.elf_so(1) no longer performs relocation.
>   Instead it loads cache from the disk file previously created and
>   compares cache information and in-memory data. If they don't differ,
>   it patches GOT/PLT pointers so that they point to locations in the
>   cache. But if they differ, ld.elf_so(1) will do the same job. 

I'm still not sure you can save the relocations and reuse them
if/when the library is loaded again.  The relocations depend
on the program (ie the entire set of objects being loaded) not
on a single library.

My experiments showed that the load time is heavily dependent
of the symbol table search time.  This is largely due to the
number of lookups that are expected to fail. Doubling (or maybe
quadroupling) the size of the dynamic symbol hash table might help.

The other change would be to increase the number of pages read in
on each fault.  I did try this, but the naive change generates a
kernel that won't load :-(

I also have a 'gut feel' that the system isn't working quite right
when it has to page in an application whose pages have been displaced
by buffered files.  The disk does too many seeks...
 
> - As time goes by, there will be more caches stored in /usr/libexec/reloc.
>   If needed, elfreld(1) daemon regularly check if they are still valid, and
>   removes invalid files.

You could do this with a script based on the file access time.

The other slight problem is that ld.elf_so runs as the user loading
the binary - so cannot generate 'secure' files.

	David

-- 
David Laight: david@l8s.co.uk