Linking with gcc increases file size to 16 KB - c

Question

I'm on linux right now. I'm compiling a super simple C program:
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
return 0;
}
and compiling with
gcc main.c -o main
After running ll to get file sizes, this is what it returns:
-rwxr-xr-x 1 xylight xylight 16K Nov 5 11:30 main
-rw-r--r-- 1 xylight xylight 68 Nov 5 11:23 main.c
-rw-r--r-- 1 xylight xylight 1.5K Nov 5 11:30 main.o
After linking main.o, the file size becomes 16KB! How can I make this smaller? Any linker options?
I'm not sure if this is a duplicate, I couldn't find anything on here. Let me know if it's a duplicate.
After running readelf -h main it says that the ELF type is this: DYN (Shared object file)
Anyone know what I could do to make this smaller?

Answer 1

I wasn't able to find a good explanation of this on SO so let me post one here.
First of all, by default executable includes static symbol table which is used for debugging and is not loaded at runtime. We can get rid of it with strip main which will save us about 2K (down to 15K on my Ubuntu 20).
Now, we can take a closer look at the overheads by running readelf -SW main:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 0000000000000318 000318 00001c 00 A 0 0 1
[ 2] .note.gnu.property NOTE 0000000000000338 000338 000020 00 A 0 0 8
[ 3] .note.gnu.build-id NOTE 0000000000000358 000358 000024 00 A 0 0 4
[ 4] .note.ABI-tag NOTE 000000000000037c 00037c 000020 00 A 0 0 4
[ 5] .gnu.hash GNU_HASH 00000000000003a0 0003a0 000024 00 A 6 0 8
[ 6] .dynsym DYNSYM 00000000000003c8 0003c8 0000a8 18 A 7 1 8
[ 7] .dynstr STRTAB 0000000000000470 000470 000082 00 A 0 0 1
[ 8] .gnu.version VERSYM 00000000000004f2 0004f2 00000e 02 A 6 0 2
[ 9] .gnu.version_r VERNEED 0000000000000500 000500 000020 00 A 7 1 8
[10] .rela.dyn RELA 0000000000000520 000520 0000c0 18 A 6 0 8
[11] .rela.plt RELA 00000000000005e0 0005e0 000018 18 AI 6 24 8
[12] .init PROGBITS 0000000000001000 001000 00001b 00 AX 0 0 4
[13] .plt PROGBITS 0000000000001020 001020 000020 10 AX 0 0 16
[14] .plt.got PROGBITS 0000000000001040 001040 000010 10 AX 0 0 16
[15] .plt.sec PROGBITS 0000000000001050 001050 000010 10 AX 0 0 16
[16] .text PROGBITS 0000000000001060 001060 000185 00 AX 0 0 16
[17] .fini PROGBITS 00000000000011e8 0011e8 00000d 00 AX 0 0 4
[18] .rodata PROGBITS 0000000000002000 002000 000012 00 A 0 0 4
[19] .eh_frame_hdr PROGBITS 0000000000002014 002014 000044 00 A 0 0 4
[20] .eh_frame PROGBITS 0000000000002058 002058 000108 00 A 0 0 8
[21] .init_array INIT_ARRAY 0000000000003db8 002db8 000008 08 WA 0 0 8
[22] .fini_array FINI_ARRAY 0000000000003dc0 002dc0 000008 08 WA 0 0 8
[23] .dynamic DYNAMIC 0000000000003dc8 002dc8 0001f0 10 WA 7 0 8
[24] .got PROGBITS 0000000000003fb8 002fb8 000048 08 WA 0 0 8
[25] .data PROGBITS 0000000000004000 003000 000010 00 WA 0 0 8
[26] .bss NOBITS 0000000000004010 003010 000008 00 WA 0 0 1
[27] .comment PROGBITS 0000000000000000 003010 00002a 01 MS 0 0 1
[28] .shstrtab STRTAB 0000000000000000 00303a 00010a 00 0 0 1
As you can see the first 1.5K (up to, but not including, the .init) hold ELF header and bookkeeping data for loading shared libraries (all those .gnu.hash, .dynsym, etc.).
This is followed by 500 bytes of code (.init, .plt, etc. up to, but not including, the .rodata). Note that code allocation starts at 4K page boundary so we waste 2.5K for padding.
Then 3.5K is wasted to realign code at 4K page boundary before ~1K of data sections (.rodata, unwinding tables, etc.). There is an interesting waste of 3K between .eh_frame and .init_array which happens due to some weird alignment between readonly and normal data (see this question for more details).
So to summarize, only a small fraction of ELF size (1.5+0.5+1=3K i.e. 20%) is really used and the rest is wasted to properly align addresses when ELF is mmaped to memory. Address alignment is needed so that dynamic loader could assign different permissions for memory pages (e.g. code pages can not be written but can be executed and for data pages permissions are reversed).