Wozu Relocation?

[Namenloser]

Zitat von Uwe Raabe:

Zitat von Namenloser:

Und wenn Relocation ausgeführt wird, dann wird vom Betriebssystem jeder einzelne Sprung gepatcht, ist das richtig? Das heißt, das Betriebssystem müsste unter Umständen Assembler-Code disassemblieren können? Denn es ist ja nicht gesagt, dass auf jeder Prozessorarchitektur die Zieladresse einfach so „als Klartext“ an einer Byte-Grenze im Code steht.

Dafür schreibt der Compiler oder Linker eine Relocation Table mit den Adressen die gepatcht werden müssen.

Ja, aber es könnte ja sein, dass ein Pointer z.B. 20 Bits lang ist und die JMP-Instruction so aussieht:

Code:

jjjj aaaa aaaa aaaa aaaa aaaa

Wobei hier jedes Zeichen für 1 Bit stehen soll. Die ersten 4 Bit kodieren die JMP-Instruktion selbst, und die restlichen 20 Bit geben die Zieladresse an.

Dann kann man nicht einfach dem Betriebssystem eine Byte-Adresse zum Patchen geben, weil die zu patchende Adresse nicht an einer Byte-Grenze anfängt.

[Bernhard Geyer]

Zitat von Namenloser:

Ja, aber es könnte ja sein, dass ein Pointer z.B. 20 Bits lang ist ...

Kann er nicht! Für ein 32-Bit Anwendung sind die Pointer immer 32 Bit lang, unter 64 Bit immer 64 Bit. "Früher" gabs mal noch 16-Bit Adressen und sowas wie Pages um mehr als 64 kByte Adressraum zu haben.

[mkinzler]

Das gilt für heutige Intelprozessoren. Bei anderen Prozessoren kann es anders sein, bzw. war es.
So hatten 8-Bit-Prozessoren 16-Bit Adressregister ( den 256 Bytes wären etwas wenig Speicher). 68000er Prozessoren hatten auch bei 16-Bit Datenbus schon 32-Bit für Prozessoren ( von denen aber anfänglich nur 24 Bit ausgewertet wurden).

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

[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?!

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