There is only a slight difference between the two.
Both behave by jumping to the next instruction, one instruction at a time, but when you step into, it will go to every instruction in assembly, other files etc. and after complete execution returns to the main.c file. This gives you the overall flow including the backend.
However, step over will always jump one instruction at a time inside the main.c file only. It will execute the instruction completely without showing you what is happening at the backend.
The behavior you describe is the behavior I would expect, but I don't see that behavior.
I find that pressing F10 (step over) will often step INTO a call, rather than stepping OVER.
I was hoping to find a solution to the incorrect behavior.
If you "step into" first and get inside some assembly or other files, then click on "step over" it will act like "step into" until it reaches an instruction in the main.c. Then it will perform as desired.
Are you saying when you tried step over in main.c file, it went out of the main.c into another file?
In any given .c file (in 35 years I have not found a different behavior in main.c), I expect F10 to execute one line of code, be it "x = 10;" or "x = f( 10);"
I would expect F11 to do the "x = 10" and execute the call INTO f(), landing on the first line of f();
What I get is an inconsistent mix of F10 and F11 behavior when I press F10. Sometimes it steps over, sometimes it steps into.
I do find this vexes me, and am looking to see if I am doing something wrong.
You will get a mix only if you F11 into a file other than main.c and then press F10. If you remain inside the main.c, then it works as expected.
Do you see a different behavior in this particular scenario?
Apparently I am confused (not that this is unusual).
You are saying that if I have code like this in main.c
and if I have code like this in somefile.c:
pressing F10 in main will do a step-over on each line, but pressing F10 in somefile.c will do a step-over on the first line and a step-in on the second?
If so, I'd characterize that as a bug in the debugger (note my sense of irony).
I'd like to bring to bear some of the Cypress documentation, neither piece of which differentiates between main.c and any other file.
F11 - Step Into - Executes a single line of code. If the line is a function call, the debugger will break at the first instruction in the function. If the line is not a function call, the debugger will break at the following line of code. Use this to verify that a line of code is doing what is expected. This function temporarily allows the processor to run until it finishes processing the instructions that make up the current line of code.
F10 - Step Over - Executes a single line of code. The debugger will break at the following line of code. If the current line of code is a function call, the function will be executed without stopping. The debugger will then stop on the next line after the function call. Use this to verify that a line of code is doing what is expected. This function temporarily allows the processor to run until it finishes processing the instructions that make up the current line of code.
As stated in the original question, I often get F11 behavior when I press F10.
Let me use your situation to better explain what I meant:
In main.c file:
Line 1: x = 10;
Line 2: x = f(10);
Line 3: y = 10;
Let the function f(num) be defined in somefile.c:
//Some functions here
Now when you step over in main.c then both the lines get executed as desired. Now suppose in line 2 you did a step into, it would go to the first line inside f(num) in somefile.c. If you step over now, it will execute the functions f1() and f2() without going into what the functions internals are. But it won't execute f(num) all together because you are already inside it.
And above case is for c files. Suppose you step into an assembly file and you do a step over, then step into and step over might act the same way unless there occurs a loop label etc. where the step over will work. You will need to come back to main.c file in this case for them to work the best.
I hope this makes sense.
If this isn't the case for you, then it would be better if you could provide your project so that I can check your build settings.
I didn't think this would be such a difficult issue.
In your example, from line 1 of f(num), pressing F10 should execute f1() and f2() in order. That is what I would consider correct behavior.
In real life, though, I find that pressing F10 here steps INTO f1(), and does not step OVER as we both agree would be correct.
No assembly language files are used in my project.
If you really think there's a project/build setting that determines how F10 works, please inform me. I cannot post my project due to IP concerns.
Thanks for your continued assistance. With me, you must feel like Sisyphus