Re: Patch not included in e2fsprogs 1.21.
On Sat Jun 16, 2001 at 03:26:59PM -0400, Ben Collins wrote:
>
> We have _always_ required (by policy) that objects for shared libs be
> compiled with -fPIC. Where have you been? That's the whole definition of
> a shared library is that it is relocatable.
One of the many beautiful things about ELF is that we can be relocatable
without being required to be PIC and waste a perfectly good register. This is
why god invented the ELF Shared object file (ET_DYN), which just happens to be
what we use for shared libraries. Rather then waste a register, the file
format is fundamentaly designed to be dynamicly relocatable, without needing
to be PIC.
The shared lib loader (ld-linux.so.2 or comparable) can read in non-PIC code
application programs (of type ET_EXEC or ET_DYN) and can read the ELF header,
locate the list of needed shared libraries (Elf32_Dyn entries of type
DT_NEEDED) in the application, then it can mmap each library in turn, read the
ELF header, which then locates for us stuff like the Section header table,
which tells use where the dynamic linker symbol table (SHT_DYNSYM) is hiding,
so we can fix up the symbol addresses using the offset from the mmaped lib
address. No PIC code needed.
PIC code has a major performance impact since one entire register is devoted
exclusively to holding the base address. The performance impact is exacerbated
on lame arches such as x86 which have far too few registers. Only non-ELF
archs (does Debian have any of those anymore?), or arches with broken linkers
or broken shared lib loaders, are going to have problems when all shared libs
are non PIC.
I understand this is policy -- specifically policy.text.gz, 4.2. This policy
makes perfect sense for a.out shared libraries (where were all the rage when
this policy was written). Does this policy still make sense?
-Erik
--
Erik B. Andersen email: andersee@debian.org, andersen@lineo.com
--This message was written using 73% post-consumer electrons--
Reply to: