Re: Merkwuerdige Adressen im Code
Alexander Bartolich
> [...]
> Gerade habe ich eines meiner Programme Disassembliert mit dem
> 'objdump' (gnu) und mir fiel etwas auf was fuer mich nicht
> nachvollziehbar ist:
>
> Die Adressen fuer Daten oder Sprungziele entsprechen nicht dem
> offset der Ausfuehrbaren Datei.
Diese Entsprechung gibt es selbst bei den einfachsten Executable-
Formaten nicht. COM-Programme unter DOS werden z.B. an den Offset
256 geladen, d.h. man muss alle Adressangaben innerhalb der Datei
um den Wert korrigieren.
> [...]
> Ist vllt. jemand in der lage mir zu erklaeren was diese Adressen zu
> bedeute haben und wie sie sich nachvollziehen lassen?
Auf modernen Systemen wie Linux werden die einzelnen Segmente eines
Programms (so wie die aller beteiligten Shared Libraries) per mmap(2)
an virtuelle Adressen eingeblendet.
http://www.muppetlabs.com/~breadbox/software/ELF.txt
--
Ich kenne die Mißverständnisse-FAQ, und sie wird oft mißverstanden.
-- Andreas M. Kirchwitz <slrne144u...@krell.zikzak.de>
Heiko Nocon
>Ist vllt. jemand in der lage mir zu erklaeren was diese Adressen zu
>bedeute haben und wie sie sich nachvollziehen lassen?
Die Position des Codes in der Datei hat so gut wie nichts mit der
späteren Position im Speicher zu tun.
Wo am Ende was landet, regelt der Loader. Dazu benutzt er die
Informationen, die im Executable stecken. Wenn du Details wissen willst,
mußt du dich also mit den Details des Exe-Formats beschäftigen.
Im übrigen muß der Loader sich nichtmal sklavisch an die Vorgaben aus
dem Executable halten. Er kann nämlich auch Codeblöcke an eine andere
Position laden als ursprünglich vorgesehen. Dann muß er allerdings auch
noch nachträglich sämtliche betroffenen Adreßbezüge anpassen. Das nennt
man relozieren. Auch das kann er unter Verwendung der Informationen aus
der Exe-Datei.
Tja, und letztlich handelt es sich bei den Adressen natürlich um
virtuelle Adressen. D.h. sie haben rein garnichts mit der Position im
physikalisch vorhandene Speicher zu schaffen.