objdump lange Adressen nach der Verknüpfung

Question

zeigt habe ich ein einfaches kleines Programm in nasm (linux):

den Befehl nasm -f elf32 -o file.o file.asm mit der Objektdatei zu erzeugen.

Wenn objdump -M intel -d file.o mit erhalte ich dieses Ergebnis:

Ich sehe, dass die von objdump gezeigten Adressen sind vernünftig, aber wenn ich tun, um die Kompilierung mit dem Befehl den ausführbaren Code zu erzeugen ld -m elf_i386 -o executable file.o; Ich erhalte die followwing Ergebnis, indem Sie auf die ausführbare Datei mit objdump:

Fragen:

1. Warum haben die Adressen so lange geworden ist, obwohl sich die ausführbare Datei ist sehr klein (500 Bytes an die meisten).
2. Auf was Adressen zeigen, bin ich sicher, dass es nicht in den Speicher zeigt, weil das Programm noch nicht geladen ist.
3. Sind sie relativ oder absolut Adressen ?? Wenn relativ, dann relativ zu was ?? und wenn absolut, wie können sie absolut sein und das Programm ist noch nicht im Speicher geladen.

Es tut mir wirklich leid, wenn diese Frage für einige von Ihnen dumm scheint, aber ich muss das wirklich verstehen, es wird mir sehr in meinem Projekt helfen.

Answer 1

Warum wurden die Adressen so lang, obwohl die ausführbare Datei sehr klein ist (höchstens 500 Byte).

Da die Standard-Ladeadresse für i386 Linux 0x8048000 ist. Diese Adresse hat absolut nichts mit wie groß oder klein dein Programm ist. Sie können es zu einer anderen Adresse mit z. -Ttext-segment=0x...000 Linker-Flag.

Wovon hängt Adressen zeigen auf, ich bin sicher, dass es nicht

Er verweist auf Adresse im Speicher wird zeigen, wo der Kernel wird die ausführbare Datei laden, bevor die Steuerung, um es vorbei. Dies wird auch als "Linked at" -Adresse bezeichnet. Sie können unter readelf -l a.out sehen, welche PT_LOAD Segmente in Ihrer Binärdatei vorhanden sind und wo sie im Speicher geladen werden.

Sind sie relativ oder absolut Adressen

Absolute.