Because libc will do it every single time a process gets started.
I'm a latency person. I've tried to talk to people about pre-linking libc
at a fixed address, and avoid all the horrible run-time linking for the
case when the pre-linked address is available. So far nobody has done
this on Linux, and it makes our process startup slower.
DEC OSF/1 does this. Libraries have pre-assigned address ranges, which
are configured on a per-machine basis using a file in /etc. (Obviously,
the system gets shipped with a default address range which most machines
use, but it's not a requirement in the architecture).
For each process, when a shared library is loaded, if the default
address range is available, it gets used, and the text pages get mapped
in and shared, and there's no nead to do any run-time linking. If for
some reason that default address range is not available, then new memory
pages have to get allocated, and then library has to be relocated for
that new location. Of course, there are nice tools available for
automatically building the library VM address assignment file based on
what libraries are available on that machine, ala ldconfig.
It also means that you don't have to pay the cost of using PIC code,
and still get the benefits of using shared libraries. After the pain of
using globally allocated shared library address ranges for a.out shared
libraries, I think some folks came to the conclusion that pre-allocated
address assignment was automatically a bad thing. But using locally
pre-allocated address assignment, ala OSF/1, I think is a good idea, and
something that we might want to consider.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/