Vscode Debugger can't break somewhere

[shikihane]

Question:
I import modm:ide:vscode into project and build and programme is properly.But when debugging, vscode cannot break the breakpoint inside the main of inside. The UI of vscode as follows:

At first I suspect that the symbol table was missing , so i have tried adding the compilation option -g and adding build option profile=debug, but is useless.
As for other funcionts of the debugger, like next and step can be used.

Target Broad: STM32F746NG Disco.
Tool Chain: arm-none-eabi-g++ 10.x.
Development Environment： Windows 7 + vscode + git bash
Code: I followed the tutorial create a project with a app folder and ext folder, the code of main.cpp copy on xxx_broad/example/blink/main.cpp. I don't modify any.

[salkinium]

Hm, that's weird. The debugger implementation of VSCode is not part of modm, so I don't know what the limitations are.

Did you "Upload (Debug)" and then "Debug (Debug)"? The profiles must match otherwise the debugger will get confused.

The inlining will transform the toggle() function into three instructions, but the debugger should know that.

[salkinium]

Did you resolve this bug @shikihane?
Otherwise I'm closing this issue soon.

[rleh]

II have also experienced the same problem, could be reproduced even without VSCode with GDB in tui mode. (For example, I wasn't able to set breakpoints in the whole main.cpp because "line does not exist".)

[shikihane]

Thank you for your concern about this issue, I have been busy with other things lately and I will focus on it these days.

[shikihane]

II have also experienced the same problem, could be reproduced even without VSCode with GDB in tui mode. (For example, I wasn't able to set breakpoints in the whole main.cpp because "line does not exist".)

That's good hint, but I tried multiple versions like arm-gcc 8,9,10 as well as also on win7,win10.Neither of them supports the tui mode.This seems to be related to the ncurses library and solving that is frustrating.

[shikihane]

I tried directly with gdb + openocd without vscode and the symptom is same.
Then I tried a simple C project that share the same gcc and openocd but it not have such symptom.
I guess that it related to some compilation options, so i want to write a build script myself to try again.
The symptom picture below:
Modm Project:

Simple C Project(generated from stm cube):

[rleh]

This are the debug compile flags used by modm:
https://github.com/modm-io/modm/blob/develop/tools/build_script_generator/common.py#L224-L225
and (in debug mode)
https://github.com/modm-io/modm/blob/develop/tools/build_script_generator/common.py#L243-L246

[rleh]

Which flags does the STM32 Cube project use (by default)?

[shikihane]

yes，that's generated from cube default .

[shikihane]

It's all hit right after comment optimize option on app/modm/SConscript:

Then they are invaid after uncomment those :

[salkinium]

If you comment out the -Og, GCC reverts to it's default optimization level, which is -O0 which may fix this issue, but it is very unoptimized resulting in a large binary and slow code.

The issue with this is that is modifies the timing behavior significantly from -Os, which can be a big issue in embedded real-time applications, and the binary may not fit anymore. So the main issue is that the act of debugging changes the behavior, which may either hide bugs or cause completely new, unrelated issues.

Therefore I chose to use -Og which seems to be -O1 without some optimizations:

-Og

Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0.

Like -O0, -Og completely disables a number of optimization passes so that individual options controlling them have no effect. Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging:

-fbranch-count-reg  -fdelayed-branch 
-fdse  -fif-conversion  -fif-conversion2  
-finline-functions-called-once 
-fmove-loop-invariants  -fmove-loop-stores  -fssa-phiopt 
-ftree-bit-ccp  -ftree-dse  -ftree-pta  -ftree-sra

Can you try if this improves enough if you only remove the -fno-* flags and leave the -Og?