Explaining readelf -S output
I'm trying to load an elf file into a MIPS simulator I made. The problem I'm having is that I don't quite understand the meaning behind the elf section header offset. When I do a segment dump, segments 25 - 31 and 33 - 35 "start" at 0x00000000 but the header states that the segment starts at an offset of some value (ex. 010190). Also at the beginning of the -S section readelf states that the headers start in memory at 0x107b4. But as can be seen in -S, the earliest memory allocation (because segment 0 is empty) is actually in segment 26 at offset 010210. Can someone explain what's going on here? I want to statically allocate all of this file into a memory array. Is there some assumption about offsets that's preventing me from doing this? And why does readelf say 0x107b4 is the header starting point?
Also, should I be running .init before I place the PC at the "entry point" specified by readelf?
EDIT: Okay, so, I did a hex dump of the executable file and I now realize that the offset is referring to the location in the actual elf file (contains elements at "addresses" 0 - 11d48.) So my question now is... how do I resolve the fact that many of the memory addresses reference address 0x00000000? They have different offsets of course but now that I know that is file specific, it means that several section alias. Do I actually use the offsets in memory addressing?
Segment 25:
0x00000000 00474343 3a202847 4e552920 332e342e .GCC: (GNU) 3.4.
0x00000010 35000047 43433a20 ...
Readelf -S output:
There are 36 section headers, starting at offset 0x107b4:
Section 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
Answer
When you are loading an ELF object file, you should load the segments, not the sections.
Load the segment if it is of type PT_LOAD.
The sections with address 0 are sections that should not be loaded. If you look at their names, you can probably guess why.
this document will help you understand the ELF format better