Why GCC executable are so bloated?

7kb of code for hello world?

>>39
Not bad, filealign + merge did the trick. Setting the entrypoint directly removed some 100+ bytes of overhead(the entrypoint function is always statically linked, as it can sometimes contain application specific information. Any functions the entrypoint used would either be linked dynamically or statically, depending on the options), however setting the entrypoint like that won't generate a portable Win32 executable (it may fail when used in some (future) Win32's or when using some executable packers/protections). The reason for this is because your code will get translated to something like(I just posted what it does on my box):

.00401016: 55                             push        ebp
.00401017: 8BEC                           mov         ebp,esp
.00401019: 6808104000                     push        000401008 ;'Hello world!' --↑1
.0040101E: FF1500104000                   call        printf
.00401024: 59                             pop         ecx
.00401025: 33C0                           xor         eax,eax
.00401027: 5D                             pop         ebp
.00401028: C3                             retn
.00401029: CC                             int         3
.0040102A: CC                             int         3
.0040102B: CC                             int         3
[code]
So you have the function prologue/epilogue (can be eliminated by increasing optimization settings, /Ox should do the trick:
[code]
00401016: 6808104000                     push        00401008 ;'Hello world!' --↑1
0040101B: FF1500104000                   call        printf
00401021: 59                             pop         ecx
00401022: 33C0                           xor         eax,eax
00401024: C3                             retn)

This code just calls printf and returns 0. So far, so good, but, did you consider to who you are returning?
Windows has traditionally placed a stub to ExitThread on the stack(

Application starts with top of stack looking like:
0012FFC4   7C816FD7  RETURN to kernel32.7C816FD7

7C816FD7    50              PUSH EAX
7C816FD8    E8 7B50FFFF     CALL kernel32.ExitThread), so you'd get the expected results (it also places a SEH handler and some other useful things), but it doesn't have to do any of that(it's undocumented behaviour), so a compliant Win32 application should call ExitProcess or ExitThread when they need to exit (or do it portably through libc).