search

modm-io / modm

modm: a C++23 library generator for AVR and ARM Cortex-M devices
https://modm.io
Mozilla Public License 2.0
719 stars 127 forks source link

Vscode Debugger can't break somewhere #777

Open shikihane opened 2 years ago

shikihane commented 2 years ago

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: image 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 commented 2 years ago

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 commented 2 years ago

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

rleh commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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: image

Simple C Project(generated from stm cube): image

rleh commented 2 years ago

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 commented 2 years ago

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

shikihane commented 2 years ago

yes，that's generated from cube default . image

shikihane commented 2 years ago

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

Then they are invaid after uncomment those : image

salkinium commented 2 years ago

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?