Why does GNU ld include a section that does not appear in the linker script? - ld

Question

I'm trying to create a minimal C example on a boot sector for educational purposes.
However, I noticed that my example was not being recognized as a boot sector because he magic 0x55aa bytes were not present as the 511th and 512th bytes.
Then, I investigated further, and it seems that this is because the .eh_frame section was getting included in the image, even though it was never mentioned in the linker script.
Why is that?
The exact setup is present here and reproduced below
build.sh:
as -ggdb3 -o entry.o entry.S
gcc -c -ggdb3 -nostartfiles -nostdlib -o main.o main.c
ld -o main.elf -T linker.ld entry.o main.o
ld --oformat binary -o main.img -T linker.ld entry.o main.o
qemu-system-x86_64 -hda main.img
linker.ld
ENTRY(mystart)
SECTIONS
{
.text : {
entry.o(.text)
*(.text)
*(.rodata)
*(.data)
/**(.eh_frame)*/
. = 0x1FE;
SHORT(0xAA55)
}
/* Reserve 16 MiB of stack. */
__stack_bottom = .;
. = . + 0x1000000;
__stack_top = .;
}
entry.S:
.text
.global mystart
mystart:
mov %rsp, __stack_top
call main
jmp .
main.c:
void main(void) {
while (1);
}
If I uncomment the .eh_frame frame above, then it gets included at the specified location, and things work, although it is not ideal and I would rather ignore that section completely.
But why does it try to include the .eh_frame in the final image if I never mention it?
I found out about .eh_frame by doing:
hd main.img
which gives:
00000000 14 00 00 00 00 00 00 00 01 7a 52 00 01 78 10 01 |.........zR..x..|
00000010 1b 0c 07 08 90 01 00 00 1c 00 00 00 1c 00 00 00 |................|
00000020 27 00 00 00 06 00 00 00 00 41 0e 10 86 02 43 0d |'........A....C.|
00000030 06 00 00 00 00 00 00 00 48 89 24 25 38 02 00 01 |........H.$%8...|
00000040 e8 02 00 00 00 eb fe 55 48 89 e5 eb fe 66 2e 0f |.......UH....f..|
00000050 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000060 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000070 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000080 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000090 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000000a0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000000b0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
000000c0 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
000000d0 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
000000e0 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000000f0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000100 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000110 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000120 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000130 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
00000140 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000150 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000160 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000170 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000180 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
00000190 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000001a0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
000001b0 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
000001c0 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
000001d0 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000001e0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000001f0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000200 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000210 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000220 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 0f 1f |...f.........f..|
00000230 84 00 00 00 00 00 55 aa |......U.|
00000238
and then:
objdump -D main.o
which contains:
Disassembly of section .eh_frame:
0000000000000000 <.eh_frame>:
0: 14 00 adc $0x0,%al
2: 00 00 add %al,(%rax)
4: 00 00 add %al,(%rax)
6: 00 00 add %al,(%rax)
8: 01 7a 52 add %edi,0x52(%rdx)
b: 00 01 add %al,(%rcx)
d: 78 10 js 1f <.eh_frame+0x1f>
f: 01 1b add %ebx,(%rbx)
11: 0c 07 or $0x7,%al
13: 08 90 01 00 00 1c or %dl,0x1c000001(%rax)
19: 00 00 add %al,(%rax)
1b: 00 1c 00 add %bl,(%rax,%rax,1)
1e: 00 00 add %al,(%rax)
20: 00 00 add %al,(%rax)
22: 00 00 add %al,(%rax)
24: 06 (bad)
25: 00 00 add %al,(%rax)
27: 00 00 add %al,(%rax)
29: 41 0e rex.B (bad)
2b: 10 86 02 43 0d 06 adc %al,0x60d4302(%rsi)
31: 00 00 add %al,(%rax)
33: 00 00 add %al,(%rax)
35: 00 00 add %al,(%rax)
...
so we can see that in the hd main.img, the first bytes are exactly the same as those in .eh_frame, and the image size is 512 + sizeof(.eh_frame) instead of the expected 512.
Tested on Ubuntu 18.04, GCC 7.3.0, binutils 2.30.