linux-mips-fnet
[Top] [All Lists]

Re: issues with non-PIC glibc on Linux/MIPS

To: Jay Carlson <nop@nop.com>
Subject: Re: issues with non-PIC glibc on Linux/MIPS
From: Ralf Baechle <ralf@uni-koblenz.de>
Date: Fri, 5 Nov 1999 08:46:10 +0100
Cc: Dominic Sweetman <dom@algor.co.uk>, linux-mips@fnet.fr, glibc-linux@ricardo.ecn.wfu.edu, linuxce-devel@linuxce.org
In-reply-to: <1221301bf23b5$14e4b990$0a00000a@nop.com>
References: <1211d01bf2149$2199ccc0$0a00000a@nop.com> <199910290847.JAA00269@gladsmuir.algor.co.uk> <19991030003913.B15510@uni-koblenz.de> <1221301bf23b5$14e4b990$0a00000a@nop.com>
On Sun, Oct 31, 1999 at 10:32:01AM -0500, Jay Carlson wrote:

> What I'm wondering is how bad we will lose if we avoid the fixup during
> loading and just nail libc.so down at a fixed address.  libc procedures
> would not need to be patched to call each other, and all data used by libc
> would be placed in memory at fixed addresses.  We would lose dynamic
> linking, but not dynamic loading for shared libraries.

The way SVr4 PIC code works it it not necessary to patch libc procedures.
This still requires performing all the R_MIPS_REL32 relocations by the
dynamic linker.  Most of this can be avoided by a concept like ``Quickstart''
which is being used by RISC/os and IRIX.  The idea is to assign load
addresses to binaries in advance and perform all relocations to this
addresses in advance on the library on disk.  If on startup the library
then can actually be mapped to the pre-relocated address most of the
relocation business can be skipped.

> One justification for including glibc-linux in the To list is that I'm
> hoping to get a feel for how much stuff will break without dynamic linking.

Ulrich Drepper has worked on a Quickstart-like scheme which is supposed
to be better.

> There are really bizarre things that can be done to fix up the memory usage
> problem.  Consider a dynamic linking setup that patched up references to
> shared symbols in the code as they were encountered---perhaps illegal
> instructions for an exception handler to resolve.  Because, in some sense,
> the code pages' semantics are not changed by this process, they can be
> freely discarded by the kernel and they'll just be fixed up the next time
> their original data gets faulted in and executed.  If the fixup handler is
> trusted, even the fixed-up pages could be shared across processes with the
> same execution environment.  An interesting thought experiment, at least.

This mixes the userspace problem of dynamic linking with the kernel side
of demand loading.  Without going into details - you'll not be able to
solve this efficiently using the current kernel API.  Again the SVr4 PIC
code model takes care of this by concentrating the necessry changes to
a much smaller number of pages.

I'd actually consider to rewrite a number of programs into smaller, more
space-efficient versions.  Multithreaded programs would have the per-process
relocation overhead only once instead of once per process.  Or have you
ever checked how much rarely needed baggage libc carries around?  A
chainsawed version of libc could help alot.

> Yeah, we should take a look at that.  It's a shame to lose the possibility
> of execute-in-place though.  I wonder if any of the ext2 compression patches
> work on linux/mips...

I don't have reports about this but I imagine that if changes are necessary
they won't be too hard.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>