Re: Shared library -shared vs. -fpic

[John Reiser <jreiser at BitWagon dot com>]

In many implementations, dlopen() actually returns Elf32_Ehdr * .
See /usr/include/elf.h .  One important pointer is
(Elf32_Phdr *)(ehdr->e_phoff + (char *)ehdr), which points to e_phnum
"segment descriptors" for an Elf file.  Check for PT_LOAD==p_type;
these are the ones that get loaded, usually by mmap().
The fields p_vaddr and p_memsz locate the segment in memory.
If 0!=(PF_X & p_flags) then the segment contains instructions.

Although some implementations will accept code that is not -fpic
and not -fPIC in an ET_DYN==e_type file, any page containing relocated
addresses will have its own copy in each process, instead of being
shared.  Thus, -fpic or -fPIC might be prefered because it tends to
increase sharing of memory pages, thus reducing the demand for memory.
Check by using "objdump --dynamic-reloc foo.so" .

The effective runtime symbol table is controlled by various RTLD_* bits
specified to dlopen() and module creation (/bin/ld).  In many cases,
the default action is that a newly-dlopen()ed module adds its symbols
onto the front of the list, hiding symbols that were loaded earlier and
having the same name.  See dlfcn.h and elf.h.

In many cases I have found the documentation to be incomplete and/or murky;
the source for glibc 2.x is the ultimate authority.  Unfortunately, it too is
often hard to follow, partly because significant pieces of it (such as _dl_start)
are written under historical assumptions that subroutines cannot be used!
Most decent architectures have long had the ability to use 'static' (file scope)
functions at runtime startup, but the code has not advanced.  In this case,
"portability" is a liability, not a benefit.  At the minimum, there should
be two versions.  The one using actual non-inline subroutines would be
much easier to understand, maintain, and improve.

-- 
John Reiser, jreiser@BitWagon.com