Why did the program entry point become 'sub esp, 1C'?

Question

I compiled the following C++ code with MinGW and opened it in OllyDbg 2.01. And the program stops at the following lines:

CPU Disasm
Address   Hex dump          Command                                  Comments
00401570  /$  83EC 1C       SUB ESP,1C
00401573  |.  C70424 010000 MOV DWORD PTR SS:[LOCAL.6],1
0040157A  |.  FF15 68814000 CALL DWORD PTR DS:[<&msvcrt.__set_app_ty
00401580  \.  E8 FBFBFFFF   CALL 00401180


Names in Project1, item 20
  Address = 00401570
  Section = .text
  Type = Export
  Ordinal =
  Name = <ModuleEntryPoint>
  Comments =

However, this is not what I want. I prefer when OllyDbg stop at the following lines:

CPU Disasm
Address   Hex dump          Command                                  Comments
004016B0  /$  55            PUSH EBP                                 ; Project1.004016B0(guessed void)
004016B1  |.  89E5          MOV EBP,ESP
004016B3  |.  83E4 F0       AND ESP,FFFFFFF0                         ; DQWORD (16.-byte) stack alignment
004016B6  |.  83EC 10       SUB ESP,10
004016B9  |.  E8 A2050000   CALL 00401C60
004016BE  |.  C70424 645040 MOV DWORD PTR SS:[LOCAL.4],OFFSET 004050 ; /format => "Hello World!"
004016C5  |.  E8 9E1F0000   CALL <JMP.&msvcrt.printf>                ; \MSVCRT.printf
004016CA  |.  B8 00000000   MOV EAX,0
004016CF  |.  C9            LEAVE
004016D0  \.  C3            RETN

Is that a bug? Why did MinGW set SUB ESP, 1C as the entrypoint? Can I set Ollydbg to start at the correct entrypoint?

Answer 1

No, this is not a bug. Likely this is because you confuse the executable's entry point address (where Olly breaks) with the address of your main() function (where you expect it to break). You should locate your main() and set a breakpoint there manually instead.

There is a lot going on behind the scene before execution flow reaches main(). The code that gets control first is hidden within the C Run-Time (CRT) library provided by your compiler and is linked in automatically when you link your executable. This code (aptly named CRT startup) is responsible for setting up various things when a C program starts up, mainly, initializes all the internals of the C runtime (there is a lot of other stuff which I won't mention here), performs C++ static objects' constructor calls, and at the end calls your main(). So to get things going, the linker sets up the entry point to inside this startup machinery, which is exactly what we observe.

Note: It is possible to strip all the CRT stuff from your executable at the expense of not having the C runtime library linked. Not sure whether this is what you would like to have.