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

[Ralf Baechle <ralf at uni-koblenz dot de>]

On Sun, Nov 21, 1999 at 11:27:28PM -0500, Jay Carlson wrote:

> But the code has still paid the price for the *potential* of having its
> symbols relocated.  All references to symbols get an indirection, and
> because gcc itself doesn't emit the PIC instructions, it depends on gas to
> rewrite the references.  And gas doesn't do much optimization, so every

The MIPS ABI describes pretty much into detail how to handle these relocs.
It doesn't make it mandatory to handle things exactly according to that
description but still everybody seems to do so.  N32 ABI seems to do
better for PIC-specific optimizations.

> > Ulrich Drepper has worked on a Quickstart-like scheme which is supposed
> > to be better.
> 
> Quickstart is a good thing, but it's not directly relevant.

It's relevant in that it's a strategy to avoid a large fraction of
relocations.  That can make a difference.

> Yeah, we've been picking those up from various sources; people working on
> x86 boot disks have been a great source of tiny apps.  uClinux has more.
> But the potential payoff of global code size reductions from toolchain
> modifications was tempting enough to distract me from that.

Agreed.

Have you looked into a few other binary format options like embedded PIC
and similar?

> glibc 2.1 by all reports is much worse.  For instance, touching just about
> anything tows in the whole internationalization package.  H.J. Lu did some
> work on that, but I don't see much interest from the glibc core team on
> fixing this kind of issue; I suppose that's a reasonable allocation of
> resources, but along with the well-known code size increase, this has made
> 2.1 a non-starter for LinuxCE projects.

Keep in mind that you still should keep the ability to internationalize
packages.  At least a hard internationalization at compile or much better
installation time should be available.

I don't believe in the concept of a libc reducer as that will produce a
libc that makes re-installation of a new libc necessary for the installation
of a new application.

> Some people have been working on compression for romfs; that might make
> sense.  But you lose any hope of eXecute In Place in either case.

Execute in place from a device as slow as a flash disk isn't a great idea
anyway.

Btw, how big is the buffer cache on your Linux/CE system on average?

I see a growing tensing between the design goal of various Linux users.
Right now we're targetting systems with as little as 4mb, maybe even less
memory.  At the same time we're trying to support systems that have
three digit numbers of processors and play in the TB league memorywise.
Fairly obvious that tradeoffs won't fit everyone.

  Ralf