J'essaie de charger un fichier elf dans un simulateur MIPS que j'ai créé. Le problème que j'ai est que je ne comprends pas très bien la signification derrière le décalage d'en-tête de la section elf. Lorsque je fais un vidage de segment, les segments 25 - 31 et 33 - 35 "démarrent" à 0x00000000 mais l'en-tête indique que le segment commence à un décalage de certaine valeur (par exemple 010190). Toujours au début de la section -S readelf indique que les en-têtes commencent en mémoire à 0x107b4. Mais comme on peut le voir dans -S, la plus ancienne allocation de mémoire (parce que le segment 0 est vide) est en fait dans le segment 26 au décalage 010210. Quelqu'un peut-il expliquer ce qui se passe ici? Je veux allouer statiquement tout ce fichier dans un tableau de mémoire. Y a-t-il des hypothèses sur les compensations qui m'empêchent de faire cela? Et pourquoi dit-on que 0x107b4 est le point de départ de l'en-tête?Explication readelf -S output
De même, devrais-je lancer .init avant de placer le PC au "point d'entrée" spécifié par readelf?
EDIT: Ok, donc, j'ai fait un vidage hexadécimal du fichier exécutable et je réalise maintenant que le décalage fait référence à l'emplacement dans le fichier elf réel (contient des éléments à "adresses" 0 - 11d48.) Donc mon question est maintenant ... comment puis-je résoudre le fait que beaucoup d'adresses de mémoire référence l'adresse 0x00000000? Ils ont différents décalages bien sûr, mais maintenant que je sais que c'est un fichier spécifique, cela signifie que plusieurs alias de section. Est-ce que j'utilise les décalages dans l'adressage mémoire?
Segment 25:
0x00000000 00474343 3a202847 4e552920 332e342e .GCC: (GNU) 3.4.
0x00000010 35000047 43433a20 ...
readelf -S sortie:
There are 36 section headers, starting at offset 0x107b4:
têtes de section:
[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