Why is the ELF header loaded into memory along with the text segment?

Question

I compiled this program with -m32 -nostdlib into an ELF executable:

void _start() {}

And when I did readelf -l I was surprised to see that the offset on the LOAD segment was 0x000000, since that would mean that the executable header would get loaded into memory at the same time as the text segment. So I checked with GDB, and that is indeed the case:

(gdb) b _start
Breakpoint 1 at 0x8048083
(gdb) r
Starting program: /home/tbodt/ish/build/a.out 

Breakpoint 1, 0x08048083 in _start ()
(gdb) x/4c 0x08048000
0x8048000:      127 '\177'      69 'E'  76 'L'  70 'F'

Why is this useful?

Maybe the dynamic linker code needs to look in the ELF header. — Barmar
@JohnBollinger I'm just not sure why having the header in memory is useful, if there wasn't a good reason for the header to be there I'd expect the offset to be 0x83 and the entry point to just be 0x8048000 — tbodt

Employed Russian Employed Russian · Accepted Answer · 2017-04-29T20:01:34

I was surprised to see that the offset on the LOAD segment was 0x000000

Why were you surprised?

since that would mean that the executable header would get loaded into memory at the same time as the text segment.

Correct. Why is that a problem?

As this answer explains, the executable is mmaped and mmap works on entire pages; you can't mmap part of the page starting at offset 0x34.

You could build an executable in which .text starts at offset 4096 (leaving a large hole between the ELF header and program headers and the text), and then such executable can have the first PT_LOAD segment with offset 4096. This isn't commonly done: the wasted space in the file usually is not worth saving 52 bytes of memory.

Why is the ELF header loaded into memory along with the text segment?

1 Answers