This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: issues with non-PIC glibc on Linux/MIPS
- To: "Jay Carlson" <nop at nop dot com>
- Subject: Re: issues with non-PIC glibc on Linux/MIPS
- From: Dominic Sweetman <dom at algor dot co dot uk>
- Date: Fri, 29 Oct 1999 09:47:42 +0100 (GMT/BST)
- Cc: <linux-mips at fnet dot fr>, <glibc-linux at ricardo dot ecn dot wfu dot edu>, <linuxce-devel at linuxce dot org>
- References: <1211d01bf2149$2199ccc0$0a00000a@nop.com>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
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