Subject: Re: NetBSD ld.elf_so vs FreeBSD ld-elf.so vs Linux ld-linux.so
To: None <tech-perform@netbsd.org>
From: Tero Kivinen <kivinen@ssh.fi>
List: tech-perform
Date: 10/06/2002 23:27:06
martin@duskware.de (Martin Husemann) writes:
> Just to make it clear: this is *not* the kind of preloading Bang Jun-Young
> is talking about. His proposal put a prefered load addres into each shared
> library, but if ld.elf_so is not able to map the lib at that address it
> falls back to the complete relocation work we currently do always. (This
> is the same way windows handles the problem, if you ever started windows
> apps in a debugger that used custom DLLs you've noticed the "Relocating..."
> messages from the runtime loader for those DLLs, but never for M$ supplied
> ones.)

I think OSF1... eee Digital unix... tru64 (I think that is the current
name of the OS) has been doing for long time. For 64-bit architecture
it is little easier, as they do have enough virtual memory to burn for
each library...

They have /usr/shlib/so_locations file which register the load address
of each shared library and they also prelink all calls from one
library to another (i.e if the library1 calls function in library2,
they will have proper address precalculate and it will be used if
library2 has the same version, size, timestamp etc than it had when
the library1 was prelinked). 

from the /usr/shlib/so_locations:
----------------------------------------------------------------------
# This is the so_locations file, describing reserved addresses for
# shared libraries.  In actuality, any .so shared library can be
# placed in memory at any address, subject to various alignment
# constraints.  However, each shared library is prelinked at some
# address, and if it can be brought into memory at that same address,
# start up time can be reduced.  Furthermore, if all libraries that
# an object depends upon have not changed and are at their 'linked'
# addresses, then even further speedups can be done.  The key to
# having this work is in choosing non-conflicting addresses for all
# shared objects.  This file is the database that implements that
# policy.  The ld utility can read and write an so_locations file
# when it creates a shared library.
#
# The two relevant ld options are:
#
#        -check_registry  <file>
#
#        -update_registry <file>
...
# The directives following this comment indicate that the system
# library addresses grow upwards, with text and data in different
# areas of memory.  This will tend to allow text page table pages
# to be shared, and minimize the number of data page table pages
# (which cannot be shared between processes).  The area below the
# first library is reserved for the dynamic loader.  We have chosen
# a fairly large padding to make it likely that rebuilt libraries
# will still fit into their original slot, to maximize quickstart
# potential.  The starting addresses chosen are not the ld default
# addresses.  This means that users who build without an so_locations
# file will still end up with libraries that are not at addresses that
# conflict with addresses in this file.
#
################################################################
#
$grow_up=1


$text_start_address=0x000003ff80080000


$data_start_address=0x000003ffc0080000


$text_align_size=0x0000000000010000 padding=0x0000000000008000


$data_align_size=0x0000000000010000 padding=0x0000000000008000


libmxr.so \
                :st = .text 0x000000007fa00000, 0x0000000000200000:\
                :st = .data 0x000000007fc00000, 0x0000000000200000:\

#
# Text segment 0x3ff80000000 - 0x3ff807fffff
# Data segment 0x3ffc0000000 - 0x3ffc07fffff
#
loader \
                :st = .text 0x000003ff80000000, 0x0000000000080000:\
                :st = .data 0x000003ffc0000000, 0x0000000000080000:\

libc.so \
                :st = .text 0x000003ff80080000, 0x0000000000150000:\
                :st = .data 0x000003ffc0080000, 0x0000000000040000:\
...
libreadline.so \
                :st = .text 0x000003ff811d0000, 0x0000000000020000:\
                :st = .data 0x000003ffc06a0000, 0x0000000000010000:\
...
libz.so \
                :st = .text 0x000003ff81340000, 0x0000000000010000:\
                :st = .data 0x000003ffc06f0000, 0x0000000000010000:\
----------------------------------------------------------------------
The last two are not system libraries but shared libraries built and
installed after the system installation. The ld added them there when
I compiled those libraries. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/