Confusions about Position Independent Code

[Marmoteer]

Hello! I was reading this excellent article about position independent code and it's implementation for shared libraries. I'm still confused about one part though. My current understanding is that the offset between the code section and data section is known at compile time. Since this offset never changes, variable references can be reassigned as the position of the currently executing instruction address plus the known offset to the data section. This is where I get confused. The author states that the variable is indirectly addressed via the Global Offset table which resides in the beginning of the DS. The addresses in the GOT are assigned at runtime. What I'm wondering is that if the data section's address is known relative to the current instruction why not just add the offset to the variable instead of going through the Global Offset Table?

To summarize if the GOT address is known relative to the code section and its offset is encoded into each variable/function reference why not just encode the relative variable address instead?

Is it that the the data section is scrambled for some reason and the GOT has the only consistent address? (0x0 I believe in the DS)

Anyway I hope my question isn't too confusing and thanks for the help.
Here's the article referred to in my question - http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/

Some relevant information:
Relocations - http://en.wikipedia.org/wiki/Relocation_(computing )
Data Segment - http://en.wikipedia.org/wiki/Data_segment
Position Independent Code - http://www.gentoo.org/proj/en/hardened/pic-guide.xml

 

[rcgldr]

This depends on the addressing modes supported by the processor. On a Motorola 68000 series processor, all memory reference instructions can be PC (program counter) relative, so position independent code just needs to use those PC relative addressing modes. On an Intel X86 processor, only the branch and call instructions are PC relative, the memory reference instructions use other registers as the base and/or index registers, so some scheme needs to be used in order to make X86 code (and data) position independent.

For windows, shared libraries are implemented as dynamic linked libraries instead of using position independent code methods. The code is shared between running processes, but usually each process has it's own copy of the dynamic linked library data. There can also be shared data with a dynamic link library. I'm not sure on the details on how the private and shared data virtual address spaces are setup. Wiki article:

http://en.wikipedia.org/wiki/Dynamic-link_library

MSDN article:

http://msdn.microsoft.com/en-us/library/ms682594

 

[Marmoteer]

Right, on Windows relocations are performed to keep the code position independent. I'm pretty sure I understand the mechanism of position independent code on x86 (using instruction relative addressing) I'm just confused why (for linux) the GOT is accessed and used to address the data indirectly when it is in the same section as the data itself. I hope that makes sense.

 

[harborsparrow]

The loader gets involved when shared libraries are concerned. When a process is first created for an executable file, all calls to shared libraries are replaced with stubs which actually call "the linking loader". The first time this code executes, the linking loader finds where the shared library ACTUALLY is at that moment and patches in the address of the shared library (and also records, by some means, that this code is using that library so the library can't be "unloaded" too early). For subsequent calls, the code jumps directly to the library without the loader being involved.

 

[harborsparrow]

Sorry--the above is for "dynamically linked libraries" (DLL's on Windows, or dynamic libraries on Linux or UNIX).

 

[harborsparrow]

Static libraries on Linux actually copy the library routines right into the executable file, which is bad is lots of ways--thus the invention of dynamic linking.