I'm trying to understand how exactly assembly code lay out to memory space. I wrote a simple assembly code which contains just a few lines of instruction and .data section. When I inspected it with GDB, I saw more stuff beyond data section which I couldn't see with objdump -section-header command. Below is output from gdb.
(gdb) x/100x &data 0x804909c <data>: 0x03020100 0x07060504 0x0b0a0908 0x050e0d0c 0x80490ac <other>: 0x00000000 0x6d79732e 0x00626174 0x7274732e 0x80490bc: 0x00626174 0x7368732e 0x61747274 0x742e0062 0x80490cc: 0x00747865 0x7461642e 0x00000061 0x00000000 0x80490dc: 0x00000000 0x00000000 0x00000000 0x00000000 0x80490ec: 0x00000000 0x00000000 0x00000000 0x00000000 0x80490fc: 0x00000000 0x0000001b 0x00000001 0x00000006 0x804910c: 0x08048074 0x00000074 0x00000027 0x00000000 0x804911c: 0x00000000 0x00000004 0x00000000 0x00000021
The end of .data section is 0x80490af, but as you can see there are more stuffs beyond .data section which I have no clue whatsoever. What exactly are they? Are they just junk or something else? What will happen if I try to access a memory beyond .data section?
When the system loads your file into memory, it does not stop reading at the end of the data section because there is no reason to, and it is more efficient not to. Since the executable says nothing is there, the code should not access it, so putting something there does not matter. It is more efficient because the system can use pages from the file system cache instead of copying the data, which saves physical memory and avoids a copy.
That being said, that is the content of the executable file after the data section on disk. If you look at the beginning of that extra data as strings, you will see that it is the names of sections in the file (the first two are ".symtab" and ".strtab"). After that comes other information from the file. This is data used by the linker or loader to parse the file, which just happens to have been placed in memory.
User contributions licensed under CC BY-SA 3.0