This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


> 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 ...

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.

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.

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 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.

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...

Jay


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]