Wozu Relocation?

[JamesTKirk]

Zitat von Namenloser:

Danke für den ausführlichen Post, aber so weit war mir das schon klar. Ich stand nur irgendwie auf dem Schlauch, wo man sowas braucht, da ich beim Speicher nur gedacht habe an: Code (relative Sprünge), Stack (auch relativ) und Heap (sowieso dynamisch). An sowas wie Konstanten oder globale Variablen hatte ich nicht gedacht.

Absolute Sprünge sind durchaus Gang und Gäbe. Calls von Subroutinen werden zum Beispiel meist mit nem Label gemacht und die sind dann absolut. Oder denke an Prozedurvariablen. Da speicherst du ja den Pointer zu der Prozedur in einer Variable und wenn der Compiler da jetzt die relative Adresse speichern würde, dann wäre die Adresse ja nur für den Punkt der Zuweisung gültig, aber nicht wenn er 2000 Befehle weiter dann letztendlich ausgeführt wird. Deswegen hat jede DLL (oder unter Linux ein Shared Object) eine Basisadresse, relativ zu der absolute Adressen angesehen werden. Die Relocationtable enthält dann die Positionen aller absoluten Adressen im Code (deren "Deklaration" und deren Verwendung), so dass Windows diese dann im Image anpassen kann. Linux macht das übrigens nicht (und Mac OS X auch nicht). Dort gibt es das Konzept von PIC, was für Position Independant Code steht. Da hält der Compiler in einem Register dann eine Global Offset Table (GOT), in der an bestimmten Offsets die Adressen von globalen Variablen, Prozeduren, etc. stehen und der dynamische Linker ist dann frei die Bibliothek an eine beliebige Stelle zu laden ohne erst noch das Image anpassen zu müssen.

Gruß,
Sven