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: Dominic Sweetman <dom@algor.co.uk>
Date: Fri, 29 Oct 1999 09:47:42 +0100 (GMT/BST)
Cc: <linux-mips@fnet.fr>, <glibc-linux@ricardo.ecn.wfu.edu>, <linuxce-devel@linuxce.org>
In-reply-to: <1211d01bf2149$2199ccc0$0a00000a@nop.com>
References: <1211d01bf2149$2199ccc0$0a00000a@nop.com>
Jay,

> Code size is pretty important for this project.  If you don't think
> this constraint is real or interesting, you can stop reading
> now. :-)

Is you main constraint in ROM, or in RAM?  If the former, you need to
store programs compressed and MIPS-16 (at any rate) becomes irrelevant.
Actually, I think MIPS-16 is probably not a good idea anyway; WinCE
doesn't use it so this class of system will only offer it by chance.

Position-independent code is not nice on MIPS.  SGI's horrible
MIPS-ABI does the job - but as you say it is profligate on memory.  

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.

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

Dominic Sweetman
dom@algor.co.uk

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