Ich versuche, eine Elf-Datei in einen MIPS-Simulator zu laden, den ich gemacht habe. Das Problem, das ich habe, ist, dass ich die Bedeutung nicht verstehe, die hinter dem Elf-Abschnittheader-Versatz steht. Wenn ich einen Segment-Dump mache, beginnen die Segmente 25 - 31 und 33 - 35 bei 0x00000000, aber der Header gibt an, dass das Segment bei einem Offset mit einem bestimmten Wert beginnt (z. B. 010190). Auch am Anfang der -Sektion sagt readelf, dass die Header im Speicher bei 0x107b4 beginnen. Aber wie in S zu sehen ist, ist die früheste Speicherzuweisung (weil Segment 0 leer ist) tatsächlich in Segment 26 bei Offset 010210. Kann jemand erklären, was hier vor sich geht? Ich möchte alle diese Datei in einem Speicherarray statisch zuweisen. Gibt es einige Annahmen über Offsets, die mich davon abhalten, dies zu tun? Und warum sagt Readelf 0x107b4 ist der Header Startpunkt?Erklärung readelf -S Ausgabe
Soll ich auch .init laufen, bevor ich den PC an den "Einstiegspunkt" setze, der von readelf angegeben ist?
EDIT: Okay, also, ich habe einen Hex-Dump der ausführbaren Datei und ich merke jetzt, dass der Offset bezieht sich auf die Position in der eigentlichen Elf-Datei (enthält Elemente bei "Adressen" 0 - 11d48) Frage ist jetzt ... wie löse ich die Tatsache auf, dass viele der Speicheradressen die Adresse 0x00000000 referenzieren? Sie haben natürlich verschiedene Offsets, aber jetzt, wo ich weiß, dass das Datei-spezifisch ist, bedeutet das, dass mehrere Sektionaliasnamen vorhanden sind. Benutze ich die Offsets bei der Speicheradressierung?
Segment 25:
0x00000000 00474343 3a202847 4e552920 332e342e .GCC: (GNU) 3.4.
0x00000010 35000047 43433a20 ...
readelf ES Ausgabe:
There are 36 section headers, starting at offset 0x107b4:
Abschnitt Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 00400134 000134 00000d 00 A 0 0 1
[ 2] .note.ABI-tag NOTE 00400144 000144 000020 00 A 0 0 4
[ 3] .reginfo MIPS_REGINFO 00400164 000164 000018 18 A 0 0 4
[ 4] .dynamic DYNAMIC 0040017c 00017c 000108 08 A 7 0 4
[ 5] .hash HASH 00400284 000284 0000bc 04 A 6 0 4
[ 6] .dynsym DYNSYM 00400340 000340 0001c0 10 A 7 1 4
[ 7] .dynstr STRTAB 00400500 000500 00023c 00 A 0 0 1
[ 8] .gnu.version VERSYM 0040073c 00073c 000038 02 A 6 0 2
[ 9] .gnu.version_r VERNEED 00400774 000774 000060 00 A 7 2 4
[10] .init PROGBITS 004007e4 0007e4 0000a8 00 AX 0 0 4
[11] .text PROGBITS 00400890 000890 000810 00 AX 0 0 16
[12] .MIPS.stubs PROGBITS 004010a0 0010a0 000090 00 AX 0 0 4
[13] .fini PROGBITS 00401130 001130 000058 00 AX 0 0 4
[14] .rodata PROGBITS 00401190 001190 000020 00 A 0 0 16
[15] .eh_frame_hdr PROGBITS 004011b0 0011b0 000034 00 A 0 0 4
[16] .data PROGBITS 10000000 010000 000030 00 WA 0 0 16
[17] .rld_map PROGBITS 10000030 010030 000004 00 WA 0 0 4
[18] .eh_frame PROGBITS 10000034 010034 0000bc 00 WA 0 0 4
[19] .ctors PROGBITS 100000f0 0100f0 00000c 00 WA 0 0 4
[20] .dtors PROGBITS 100000fc 0100fc 000008 00 WA 0 0 4
[21] .jcr PROGBITS 10000104 010104 000004 00 WA 0 0 4
[22] .got PROGBITS 10000110 010110 00007c 04 WAp 0 0 16
[23] .sbss NOBITS 1000018c 010190 000000 00 WAp 0 0 1
[24] .bss NOBITS 10000190 010190 000020 00 WA 0 0 16
[25] .comment PROGBITS 00000000 010190 00007e 00 0 0 1
[26] .debug_aranges MIPS_DWARF 00000000 010210 000058 00 0 0 8
[27] .debug_info MIPS_DWARF 00000000 010268 000146 00 0 0 1
[28] .debug_abbrev MIPS_DWARF 00000000 0103ae 000020 00 0 0 1
[29] .debug_line MIPS_DWARF 00000000 0103ce 0001a6 00 0 0 1
[30] .pdr PROGBITS 00000000 010574 000100 00 0 0 4
[31] .mdebug.abi32 PROGBITS 00000000 010674 000000 00 0 0 1
[32] .rel.dyn REL 004007d4 0007d4 000010 08 A 6 0 4
[33] .shstrtab STRTAB 00000000 010674 00013f 00 0 0 1
[34] .symtab SYMTAB 00000000 010d54 000920 10 35 107 4
[35] .strtab STRTAB 00000000 011674 0006d4 00 0 0 1