Re: Shared libs with non-PIC code on i386
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."