Trying to debug with no breakpoint selected works as expected.
But calling the debugger with an active breakpoint (or with the option "Always break on entry-point" enabled) results in an assembly listing.
On the other hand, even with the option "Always break on entry-point" disabled the debugger breaks right there.
Am I missing any special setting?
(I didn't include a listing because I believe that this behavior is not code-related.)
Werner
"Always break on entry-point" breaks at the entry-point of the module (startup code), which usually leads to main()/WinMain()/DllMain(), but could possibly lead to something else (for a custom build).
I can't immediately reproduce your other problem.
Not sure it helps, but a completely different approach is to use the breakpoint "statement":
__debugbreak();
which will always break in debug builds, but is a no-op in release builds.
Thanks for your response.
The reported issue can be reproduced by the following small program.
- Starting the debugger with no breakpoint set, works fine.
- Starting the debugger with a breakpoint set on the output line (line 7), results in an assembly listing.
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
system("dir");
puts("After system().");
return 0;
}
Is this an expected behavior?
Werner
Thank you for the example. I get the same effect on my machine (Windows 10, version 2004) for this program, but not for other (similar) programs(!).
The debugger apparently receives a request for a breakpoint in cmd.exe, which is where it stops (no source code, so assembly code). If I use "Debug"->"Go", or press F5, the debugger continues to the example program and stops at the breakpoint on puts(), as I expect.
At the moment I don't know if this is a new Microsoft "feature", or what is going on, to be honest...
I will continue to investigate, but unclear when I have an answer...
I ran the test code on a Windows 7 machine with PellesC version 9. Here is what I found so far.
If I debug the program without ever selecting any debug information I get a notice that there is no debug information then after acknowledging that I get an assembly code display. The same thing happens regardless of setting a breakpoint or not.
Next I selected debug data on all Project Option pages which have the option to include debug data.
Then debugging the program it shows the same outputs that are being discussed: Debug with no breakpoint stops at line 4(main entry), then pressing F5 continues and shows assembly listing. Debug with a breakpoint on line 7 skips the stop at line 4 and proceeds immediately to the assembly listing.
This all seems to make some sense to me. If I'm debugging without breakpoints wouldn't I want the debug to initiate at the start procedure so that I could step thru? I added a small procedure in front of main then have main call it after puts(). Debug without breakpoint still starts a main.
Caveat is I rarely use debug ( I could not even find "Always break on entry-point" setting) so maybe the only thing of value here is that the debug behavior is the same on windows 7 with PellesC version 9 as it is on windows 10 with PellesC version 10.
John Z