= `.data` section
`.data` is section 1:
``
00000080 01 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 |................|
000000a0 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000b0 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
``
* 80 0: `sh_name` = `01 00 00 00`: index 1 in the `.shstrtab` string table
Here, `1` says the name of this section starts at the first character of that section, and ends at the first NUL character, making up the string `.data`.
`.data` is one of the section names which has a predefined meaning according to http://www.sco.com/developers/gabi/2003-12-17/ch4.strtab.html[]:
> These sections hold initialized data that contribute to the program's memory image.
* 80 4: `sh_type` = `01 00 00 00`: `SHT_PROGBITS`: the section content is not specified by ELF, only by how the program interprets it. Normal since a `.data` section.
* 80 8: `sh_flags` = `03` 7x `00`: `SHF_WRITE` and `SHF_ALLOC`: http://www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#sh_flags, as required from a `.data` section
* 90 0: `sh_addr` = 8x `00`: TODO: standard says:
> If the section will appear in the memory image of a process, this member gives the address at which the section's first byte should reside. Otherwise, the member contains 0.
but I don't understand it very well yet.
* 90 8: `sh_offset` = `00 02 00 00 00 00 00 00` = `0x200`: number of bytes from the start of the program to the first byte in this section
* a0 0: `sh_size` = `0d 00 00 00 00 00 00 00`
If we take 0xD bytes starting at `sh_offset` 200, we see:
``
00000200 48 65 6c 6c 6f 20 77 6f 72 6c 64 21 0a 00 |Hello world!.. |
``
AHA! So our `"Hello world!"` string is in the data section like we told it to be on the NASM.
Once we graduate from `hd`, we will look this up like:
``
readelf -x .data hello_world.o
``
which outputs:
``
Hex dump of section '.data':
0x00000000 48656c6c 6f20776f 726c6421 0a Hello world!.
``
NASM sets decent properties for that section because it treats `.data` magically: https://www.nasm.us/doc/nasmdoc7.html#section-7.9.2
Also note that this was a bad section choice: a good C compiler would put the string in `.rodata` instead, because it is read-only and it would allow for further OS optimizations.
* a0 8: `sh_link` and `sh_info` = 8x 0: do not apply to this section type. http://www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#special_sections
* b0 0: `sh_addralign` = `04` = TODO: why is this alignment necessary? Is it only for `sh_addr`, or also for symbols inside `sh_addr`?
* b0 8: `sh_entsize` = `00` = the section does not contain a table. If != 0, it means that the section contains a table of fixed size entries. In this file, we see from the `readelf` output that this is the case for the `.symtab` and `.rela.text` sections.
Back to article page