Re: Shared libs with non-PIC code on i386

[David Schleef <ds@schleef.org>]

On Thu, Aug 16, 2001 at 08:20:45PM +0100, Philip Blundell wrote:
> >ld.so on some other arch's can't handle relocations outside of those used
> >by PIC code. IMHO this is something that should be fixed, but I understand
> >the glibc folks disagree..
> 
> Do you know which glibc folks in particular, and why it is that they disagree?
> 

I can't talk for the glibc developers, but I can explain a few
reasons why I didn't implement it in uClibc's ld.so on PowerPC.

 - it encourages, or rather doesn't discourage, poor programming.
   (The technical merits of this argument are lacking... =) )
 
 - currently, ld.so runs in lazy linking mode.  An unresolved
   jump, for example, will initially jump to a location in the
   linker that will fix the jump, and continue on.  Non-PIC
   jumps need to be resolved at startup, which means reading in
   the entire binary (think: no lazy paging in of the binary.)
 
 - non-PIC relocs are in shared, read-only code pages, wheras PIC
   relocs are in writable arrays.  Linking non-PIC code means that
   you have a process-specific copy of the code page.  (think:
   no more shared code.)
 
 - it requires ld.so to have a dynamic memory allocator in order
   to work.  PIC jumps are pre-allocated.

I'm sure there are other reasons, possibly even showstoppers, that
I'm not thinking of.  But until recently, the only argument for
allowing non-PIC code was "I don't know how to use -fPIC."



dave...