I compiled the following C++ code with MinGW and opened it in OllyDbg 2.01. And the program stops at the following lines:CPU DisasmAddress   Hex dump          Command                                  Comments00401570  /$  83EC 1C       SUB ESP,1C00401573  |.  C70424 010000 MOV DWORD PTR SS:[LOCAL.6],10040157A  |.  FF15 68814000 CALL DWORD PTR DS:[<&msvcrt.__set_app_ty00401580  \.  E8 FBFBFFFF   CALL 00401180Names 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 DisasmAddress   Hex dump          Command                                  Comments004016B0  /$  55            PUSH EBP                                 ; Project1.004016B0(guessed void)004016B1  |.  89E5          MOV EBP,ESP004016B3  |.  83E4 F0       AND ESP,FFFFFFF0                         ; DQWORD (16.-byte) stack alignment004016B6  |.  83EC 10       SUB ESP,10004016B9  |.  E8 A2050000   CALL 00401C60004016BE  |.  C70424 645040 MOV DWORD PTR SS:[LOCAL.4],OFFSET 004050 ; /format => Hello World!004016C5  |.  E8 9E1F0000   CALL <JMP.&msvcrt.printf>                ; \MSVCRT.printf004016CA  |.  B8 00000000   MOV EAX,0004016CF  |.  C9            LEAVE004016D0  \.  C3            RETNIs that a bug? Why did MinGW set SUB ESP, 1C as the entrypoint? Can I set Ollydbg to start at the correct entrypoint?
Why did the program entry point become 'sub esp, 1C'?
ollydbg;debugging;c++
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.