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

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

To: Dominic Sweetman <dom@algor.co.uk>
Subject: Re: issues with non-PIC glibc on Linux/MIPS
From: Ralf Baechle <ralf@uni-koblenz.de>
Date: Sat, 30 Oct 1999 00:39:13 +0200
Cc: Jay Carlson <nop@nop.com>, linux-mips@fnet.fr, glibc-linux@ricardo.ecn.wfu.edu, linuxce-devel@linuxce.org
In-reply-to: <199910290847.JAA00269@gladsmuir.algor.co.uk>
References: <1211d01bf2149$2199ccc0$0a00000a@nop.com> <199910290847.JAA00269@gladsmuir.algor.co.uk>
On Fri, Oct 29, 1999 at 09:47:42AM +0100, Dominic Sweetman wrote:

> I don't know Linux well enough to understand how deep its reliance on
> PIC code is - I assume that at least code-position-independence is
> essential for shared libraries.  But what about data?  Specifically,
> is it essential for Linux to run libraries whose static data lives at
> virtual locations which are relocated when a program is loaded?
> That's equally difficult on x86, after all.

The way shared libraries work is identical to IRIX 5.  We just don't use
the extensions of IRIX ELF over MIPS ABI ELF.

> If you don't need the data relocation, MIPS-ABI is a huge overkill.

Agreed.  However Linux does rather agressive copy on write as an
optimization.  Without PIC code alot of addresses would have to fixed
up during loading.  This would reduce the number of shared pages that
far that the total memory consumption would actually increase
significantly.  Resulting from this also physically indexed caches
would loose efficiency ...

This system is clearly a special case, I wouldn't wonder if a compressed
ROMFS-like filesystem would since space seems to be more important than
performance in this case.

  Ralf

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