No line in file (from break-insert)

[pearson]

I'm not certain if this is an issue related to cortex-debug or not, since it seems like it might be a configuration issue, but it a problem I have not had with VS Code before. (My previous experience with the debugger is through PlatformIO. This is my first try at building for ARM without PlatformIO.)

I'm using Windows 10, VS Code with the C++ extension, and a J-Link EDU Mini.

When I start a debug session with cortex-debug, VS Code opens my main.cpp and the program halts at the start of the main function as expected. However, regardless of what line a breakpoint is set on, a message such as the following will appear.

"No line 19 in file "c:\Projects\Mbed\blinky1\main.cpp". (from break-insert "c:\\Projects\Mbed\\blinky1\\main.cpp:19")

What's really odd about this is that I can step through the code and VS Code seems to recognize the lines. For example, if you look at the call stack in this screenshot where I stepped through to line 19, VS Code clearly realizes that the program is currently halted on line 19. Below that in "breakpoints" it shows that there should be a breakpoint at line 19, but then there's that error message on the bottom right.

I've dug through the various cmake logs and it appears that the proper flags are set, and (as shown in the screenshot) it appears to be reading the symbols from the binary.

Any suggestions as to what is going on here would be appreciated!

[haneefdm]

Unfortunately, I have no clue. But this is a message coming from gdb. But it looks like it actually set the breakpoint but complained anyways? I see line 19 in the Breakpoints section in the sidebar.

What happens if you leave the breakpoint there and restart using the restart button?

Also, at the bottom, at the Console window prompt can you type info breakpoints? Although a bad idea, see if you can set/remove breakpoints from there. It is a bad idea because VSCode and gdb will be out of sync on what breakpoints are set/enabled/disabled, but for an experiment's sake, try it.

[pearson]

In the case of that screenshot, I had stepped forward to the line that had the breakpoint -- the breakpoint itself will not trigger.

If I restart it will run forever. The breakpoints simply don't trigger. (In the case of the code in the screenshot, the debugger will actually disconnect because ThisThread::sleep_for will put the CPU into sleep mode. However, if that line is removed it will run forever.)

Typing info breakpoints is interesting, and it looks like it makes your point about VSCode and gdb being out of sync:

info breakpoints
No breakpoints or watchpoints.
{"token":52,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}

Do you have any thoughts as to what to look at next? (And thanks for the help so far!) This is outside of my area of knowledge...

[pearson]

@haneefdm , thanks for your input. It led me (a bit indirectly) to the answer. I saw this line in the debug console on one run: 0x000001ec in nrf_gpio_pin_set (pin_number=<optimized out>) at ../mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/modules/nrfx/hal/nrf_gpio.h:618

Obviously some optimizations were still taking place, despite my -O0 flag. I did some more digging and found that a "CLI 2" Mbed project has debug flags in two different files, and that -Og is a problem. Looking at the ninja.build file that's created, I had -g2 -O0 -ggdb2 set, but further into all the compiler flags was that -Og.

I'm not certain why -Og does not work, but I think it is related to the J-Link EDU Mini. In the past I had a similar odd problem with it and PlatformIO, and other people that reported the problem were also using the J-Link EDU Mini.

Anyway, thanks again!

[haneefdm]

-Og ... people use it and not sure what it does. It is not even documented on gcc.

I do the same as you. -g2 -O0 and even then some stuff disappears -- especially local variables getting sucked into registers and linker level optimizations removing golbal/static variables entirely.

[pearson]

This document lists it. Supposedly it is to "optimize debugging experience."

-Og enables all -O1 optimization flags except for those that may interfere with debugging

Except that it apparently does interfere with debugging in some cases... 😄

[haneefdm]

I was looking at this and it does not list it

Version dependent I guess.

[ddB0515]

I know issue is closed but had same issue on VS Code and Zephyr RTOS Si if someone have same issue please add to proj.conf CONFIG_NO_OPTIMIZATIONS=y

and will work :)

[pearson]

@ddB0515 , was that with a J-Link EDU Mini?

[ddB0515]

@ddB0515 , was that with a J-Link EDU Mini?

Yes :) why :thinking:

[pearson]

There may not be a connection here, but I've seen another oddity with the EDU Mini and the -Og optimization flag. When building a Zephyr project with VSCode and PlatformIO, debugging hangs at the message "Starting target CPU...".

When searching for this problem, the only references I found were from people using the EDU Mini. I can't say for certain that the EDU Mini is the issue as I don't have another debug probe to test with.

Anyway, I posted about the issue on PlatformIO's GitHub, in case you're curious.

[ddB0515]

That is interesting, will try over weekend to debug with OpenOCD and Blue Pill(as BMP) and check if will be the same as with JLink Thanks for pointing it out

[pearson]

I look forward to hearing your results!