Wozu Relocation?

[Namenloser]

Richtig, und bei speziellen (Mikro-?)Prozessoren gibt es soweit ich weiß auch Pointer-Längen, die kein Vielfaches von 8 sind.

[himitsu]

Weiß Jemand, wie diese Relocationstabellen aufgebaut sind?

Entweder man gibt da mit an, was wie angepasst werden muß (bei jeder Stelle einzeln oder indem man Gleiches gruppiert),
oder man analysiert die Stelle, welche angepasst werden muß,
oder man definiert, daß die anzupassenden Stellen immer nur ein bestimmtes Format haben können/dürfen.

Ersteres und Letzeres ist einfacher und ich würde Eines davon verwenden,
denn es gibt nicht nut Jumps anzupassen, sondern auch "Zeiger" auf betimmte Resourcen, wie z.B. vielen String-Konstanten im Code.

[Namenloser]

Zitat von himitsu:

es gibt nicht nut Jumps anzupassen, sondern auch "Zeiger" auf betimmte Resourcen, wie z.B. vielen String-Konstanten im Code.

Stimmt, daran hatte ich gar nicht gedacht. Da macht Relocation auch Sinn.

[BUG]

Zitat von himitsu:

Weiß Jemand, wie diese Relocationstabellen aufgebaut sind?

Wenn du das wirklich wissen willst, ist vermutlich die Dokumentation des PE-Formats ein guter Recherche-Startpunkt.

Zitat von Namenloser:

Da macht Relocation auch Sinn.

Ich denke, warum Relocation Sinn macht, ist leicht zu erkennen: Adresskonflikte bei Laufzeitbibliotheken, Address-Randomisierung (Sicherheit) oder Kompaktierung (bei Maschinen ohne virtuelle Adressen). Wie es gemacht wird und welche Ansprüche dabei an den Code / Objektdateien gestellt werden, ist eine andere Sache.

Wenn man nur relativ (von wo aus auch immer) adressiert und das von der Hardware unterstützt wird, dann braucht man keine Relocationstabellen. Je mehr Adressierungsarten unterstützt werden, desto komplizierter werden auch die Tabellen (oder sonstige Methoden).

[Aphton]

Also ich hab das noch grob in Erinnerung, sind bereits zwei Semester her seit der BS VO xD

Im Grunde ist es ja so, dass DLLs als Shared Memory Objekte geladen werden, sprich das Betriebssystem weiß, ok, an diesem Modul wird sich im Speicher kaum etwas ändern, laden wirs ein einziges mal und jedesmal, wenn eine Anwendung, egal welche und wie viele, darauf zugreifen wollen, kriegen sie dieselbe Adresse im Hauptspeicher bzw. dieselbe (=einzige) Instanz des Moduls.
Folglich kann es der Fall sein, dass z.B. mehrere DLLs konfliktäre Anfangsadressen haben. Die DLL wird dann auf eine bestimmte andere freie Stelle im Speicher geladen/gemappt und die Relocation wird angewandt.
Ich weiß jetzt nicht genau, inwiefern Virtualisierung bei shared Objekten stattfindet..

Beispiel:

Code:

Shared Objekt "X":
Basisadresse: 10
Größe: 100
Adressraum: 10..110

Shared Objekt "Y":
Basisadresse: 100
Größe: 50
Adressraum: 100..150

- X wurde geladen, Y soll nun geladen werden
- Adressraum bereits belegt, Relocation muss stattfinden
-- Y an eine freie und genügend große Stelle laden
-- alle absoluten Adressen dementsprechen neu berechnen
(hier hilft dann evt. die Relocation Table iwie, kA. wie genau; relative Adressen werden übrigens nicht angerührt, was ja Sinn macht)

Dasselbe gilt im Grunde auch für non-shared Memory Objekte (Exe?). Deren Adresse kann auch mit bereits geladenen DLLs kollidieren.
Achja, wie genau dann die Relocation funktioniert weiß ich auch nicht. Das haben wir, glaub ich, gar nicht in Detail durchgenommen.

Bin mir da aber absolut nicht mehr sicher. Du kannst dir da vlt. etwas besseres daraus reimen?!

[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.

[BUG]

Zitat von Aphton:

Achja, wie genau dann die Relocation funktioniert weiß ich auch nicht. Das haben wir, glaub ich, gar nicht in Detail durchgenommen.

Weil es relativ nutzloses Wissen ist. 99% der Studenten werden niemals damit zu tun haben. Die, die es wissen müssen, weil sie entweder Loader oder Compiler/Linker schreiben, müssen sich eh mit der entsprechenden Dokumentation auseinandersetzen.

Das es passiert, ist wichtig zu wissen.
Warum es nötig ist, ist wichtig zu wissen.
Was allgemein gemacht wird / werden kann, ist relativ trivial.
Was im Detail passiert ist ziemlich System-spezifisch und interessiert nur sehr wenige.

[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

[Zacherl]

Wenn du mehr über den Aufbau der .reloc Section wissen willst, schau mal hier rein:
http://msdn.microsoft.com/en-us/libr.../gg463119.aspx

Grob gesagt enthält die Tabelle (unter x86 und x64) die direkten Offsets zu den absoluten Adressen. Opcodes, Prefixes, etc. werden sozusagen einfach übersprungen. Unter Verwendung sind zur Zeit (bei Windows Kompilaten) nur zwei verschiedene Relocation Typen. Bei beiden wird erst die Differenz zwischen gewünschter ImageBase und reeller ImageBase gebildet und dann zur Adresse addiert.

BASED_HIGHLOW kommt hierbei bei 32 bit Kompilaten vor und besagt, dass die Zieladresse 32 Bit lang ist. 64 Bit Kompilate verwenden stattdessen BASED_DIR64, um zu signalisieren, dass volle 64 Bit für eine Adresse verwendet werden.

Laut Dokumentation gibt es noch weitere (zZ. unbenutze Typen), welche beispielsweise auch 16 Bit Adressen signalisieren könnten.

[Namenloser]

Okay, danke für die Info. (Das ist mal wieder typisch Microsoft, das Dokument nur als Word-Document bereitzustellen... ich habe hier gerade kein Programm um sowas zu öffnen.)