Wozu Relocation?

[himitsu]

Zitat von Namenloser:

(ich habe hier gerade kein Programm um sowas zu öffnen.)

Ich hab immer ein OpenOffice Portable an meinem Schlüsselbund (USB-Stick).

[p80286]

Zitat von JamesTKirk:

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.

Meine Assemblerzeiten sind schon ziemlich lange her, aber wird die Adressierung nicht immer relativ zu CodeSegment und/oder DatenSegment vorgenommen?

Einzige mir bekannte Ausnahme, das "Video-Segment" und die Interrupttabelle. Und auch da gehörte es zum guten Ton, den Segmentwert in einer Konstanten/Variablen vorzuhalten um auf evtl. Verschiebungen reagieren zu können.

Gruß
K-H

[BUG]

Zitat von p80286:

Meine Assemblerzeiten sind schon ziemlich lange her, ...

Scheint so
Das Ganze funktionierte mit segmentierten Speicher (z.B. auf Intel-Maschienen). Heutzutage ist diese Adressumsetzung abgeschaltet, weil es niemand mehr ernsthaft benutzt.
Zwar gibt es noch Legacy-Unterstützung, aber es war damals schon langsam und heute wird es nicht viel besser sein.

[Mikkey]

Zitat von p80286:

Meine Assemblerzeiten sind schon ziemlich lange her, ...

Wohl wahr, Segmente gibt es seit den 32-Bit-Zeiten nicht mehr (18 Jahre her?). Aber Nomen est Omen...

[JamesTKirk]

Zitat von p80286:

Zitat von JamesTKirk:

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.

Meine Assemblerzeiten sind schon ziemlich lange her, aber wird die Adressierung nicht immer relativ zu CodeSegment und/oder DatenSegment vorgenommen?

Wie der Rest schon gesagt hat: unter 32 (und 64) Bit gibt es keine Segmente mehr. CS und DS sind fest auf 0 gesetzt, FS wird von Microsoft verwendet, um in FS:0 den Thread Execution Block zu speichern (bei 32 Bit, bei 64 Bit ist das glaub ich GS) und GS ist soweit ich weiß auch 0. Somit erklärt sich das mit absoluten Sprüngen von selbst.

Gruß,
Sven

[p80286]

Danke für die Erläuterung, ich bin davon audsgegangen, das CS und Konsorten vom Loader vorbelegt werden.

Gruß
K-H

[implementation]

Zitat von JamesTKirk:

Dort gibt es das Konzept von PIC, was für Position Independant Code steht.

PIC und Relocation hat doch nichts mit Windows oder Linux zu tun. Wenn ich auf Windows -fPIC übergebe, kriege ich da doch auch PICode, und wenn ich auf Linux kein -fPIC angebe, kriege ich da relozierbaren.

[JamesTKirk]

Ähm, nein (zumindest, wenn du von FPC sprichst). Unter Windows wird -fPIC ignoriert (da sollte auch eine entsprechende Warnung vom Compiler generiert werden) und bevor du fragst: ich hab das im Compiler Quellcode verifiziert. Alle vier Windows Targets (i386-win32, x86_64-win64, arm-wince, i386-wince) setzen das Flag tf_no_pic_supported . Selbst, wenn du unter Windows PIC Code generieren würdest, kämest du um Relocations allerdings nicht herum, da dies ja auch die restlichen Daten im Image betrifft.
Und unter Linux ist der wichtige Punkt, dass Linux nicht reloziert. Ein ELF Image hat keine Relocation Table, also kann der dynamische Linker auch nicht wissen, was er wohin verschieben muss.
Unter Linux kommt man um PIC quasi nicht herum, während du unter Windows quasi um Relocation nicht herum kommst.

Gruß,
Sven

[implementation]

Zitat von JamesTKirk:

Unter Linux kommt man um PIC quasi nicht herum, während du unter Windows quasi um Relocation nicht herum kommst.

Ich bekam gerade beim Kompilieren von kde-base/kdelibs auf Gentoo GNU/Linux folgende Fehlermeldung:

Zitat:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/kdecore.dir/kernel/kstandarddirs.o: warning: relocation against `KStandardDirs::realFilePath(QString const&)' in readonly section `.text'.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/kdecore.dir/localization/klocalizedstring.o: relocation R_X86_64_PC32 against symbol `KLocalizedString::KLocalizedString(char const*, char const*, char const*)' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value

Ich will jetzt nicht die Problemlösung diskutieren, aber die Meldung weist für mich darauf hin, dass auch hier Relocation möglich ist (und die GNU Build Chain dies sogar als Standardfall annimmt).

Und die Wikipedia sagt sogar:

Zitat:

The ELF executable format and SO shared library format used by most Unix-like systems allows several types of relocation to be defined.

Und so sieht die Tabelle wohl aus.