
A ToC of the 20-part linker essay (2008) - _qc3o
http://lwn.net/Articles/276782/
======
userbinator
As someone who has worked far more with dynamic linking in Windows the ELF
system has always seemed needlessly complex; the extra indirections of the
GOT/PLT mechanism and PIC are avoided by simply linking DLLs with different
load addresses (so they don't always need to be relocated, but can be if
necessary), and the only thing that needs to be associated with a symbol is an
address. Makes it especially convenient when writing things like in-memory
executable compression and shared data between processes. The ability to
"import X from Y" easily is also nice.

Anyone with experience from the other side (working with ELFs and then moving
into Windows) want to share their views?

~~~
yew
I don't have much experience with the Windows model, but if I'm understanding
you correctly . . .

ELF does support load-time relocation, as appears to be done under Windows if
two base addresses conflict. That just isn't the standard way of doing things,
for several reasons.

First, load-time relocation imposes a cost at startup (whereas PIC imposes a
smaller cost throughout the lifetime of the process). I'm given to understand
that, back in the day, the startup delay for programs using large shared
libraries could be quite noticeable.

Second, load-time relocation reduces in-memory text section sharing in the
case where relocation is performed. If your goal in using shared libraries is
saving RAM, this is a problem.

Third, it's a matter of inertia. Originally, UNIX shared libraries (a.out
format) were built with a static, non-relocatable base address. Library
authors had to coordinate via a central authority to ensure compatibility. PIC
seemed like a good way to get as far away from that problem as possible - or
so I understand.

Indirection through the GOT/PLT also serves another purpose, even in load-time
relocation code - it enables replacing a symbol in one shared library with a
symbol from another (eg via LD_PRELOAD). Though that's more of a side benefit
than a justification.

~~~
quotemstr
Keep in mind that you don't need text relocations for code sequences that are
naturally PC-relative, like jumps on x86, or pretty much anything on ARM and
amd64. Windows DLLs don't need text relocations for references to other
modules: the IAT (Import Address Table) does pretty much the same thing as the
GOT and in pretty much the same way.

~~~
brigade
Um, ARM by default is very not PIC; loads have only a 4k offset so references
to the data section are stored as absolute addresses in the text section,
unless you explicitly specify PIC which adds another 'add rN, pc' instruction
to each reference. (and actually I believe Windows doesn't even support these
PIC references in ARM code)

------
rayiner
See also: [http://www.iecc.com/linkers/](http://www.iecc.com/linkers/)

------
bookface
If anybody prefers a .mobi: [http://www.filedropper.com/linkers-
ianlancetaylor](http://www.filedropper.com/linkers-ianlancetaylor)

(If anyone has a suggestion for a good place to upload that, let me know. I
don't know whether the site I found on Google is sketchy.)

