.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 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.datasection. - 80 8:
sh_flags=037x00:SHF_WRITEandSHF_ALLOC: www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#sh_flags, as required from a.datasection - 90 0:
sh_addr= 8x00: TODO: standard says:but I don't understand it very well yet.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.
- 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 00000200 48 65 6c 6c 6f 20 77 6f 72 6c 64 21 0a 00 |Hello world!.. |readelf -x .data hello_world.owhich outputs:Hex dump of section '.data': 0x00000000 48656c6c 6f20776f 726c6421 0a Hello world!.NASM sets decent properties for that section because it treats.datamagically: www.nasm.us/doc/nasmdoc7.html#section-7.9.2Also note that this was a bad section choice: a good C compiler would put the string in.rodatainstead, because it is read-only and it would allow for further OS optimizations.- a0 8:
sh_linkandsh_info= 8x 0: do not apply to this section type. 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 forsh_addr, or also for symbols insidesh_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 thereadelfoutput that this is the case for the.symtaband.rela.textsections.
- a0 8:
New to topics? Read the docs here!