Alexandre Oliva wrote:
| libtool will compile all code that might go into a shared library with
| -fPIC or equivalent, but it may end up not creating a shared library
| due to inter-library dependencies.  Unless you --disable-shared, of
| course, in which case only static libraries will be created for sure.
| If the ABI was really different from PIC to non-PIC code, I don't
| understand how the compiler could emit code to call a function before
| knowing whether it will be in a static or a shared library, so they
| can't be so different.

The whole point of position-independent code is to avoid having the linker
modify the code to perform any relocations.  Shared libraries profit from
this, because multiple mappings of the same shared library can share core.

On the m68k, instructions exist for calling a subroutine given an
absolute address, and calling given a PC-relative address.  The default
code in trampolines.c uses the PC-relative form; this will work correctly
on both PIC and non-PIC code as long as the trampolines.c code is linked
into the same library as soft_fixup_trampoline().  The linker computes
the offset between the call and the target, which remains invariant
thereafter.  The linker is capable of recording a PC-relative fixup
requirement, and this is resolved at the time the shared library is
created.

Data gets messier.  In order to have position-independent references to data,
the shared library system maintains a data structure called the global
offset table.  I think this is located in a page of memory located just
beyond the code of the shared library.  When ld.so links in the shared
library, this page gets clobbered (and therefore the VM system creates
a separate copy for each process) because the linker fills in slots of
the global offset table with the addresses of the functions and data items
that the shared code references.  For example, a reference to a global variable
"foo" goes something like this:

  p = GLOBAL_OFFSET_TABLE[slot_for_foo];
  local_foo = *p;

This differs from non-PIC code, but since this is not used in the trampoline,
it doesn't matter.  The trampoline makes a reference to soft_fixup_trampoline()
only, which the linker can fix up at shared library creation time.