breakpoints are not verified when remote debugging over ssh

[JelleRoets]

When starting a (gdb) debugging session on the remote over ssh (so specifying the ssh object in the launch.json properly), all of my breakpoints turn into a "Unverified Breakpoint" state... but still work correctly

What does "Unverified Breakpoint" mean? And why are they "Unverified" while they just work, my program breaks correctly on the breakpoints and I can add / remove breakpoints on the fly...

[WebFreak001]

Unverified means that code-debug sent the debug breakpoint requests but didn't get a response that they were successfully added (pending breakpoints)

It could be that breakpoints there do or don't work. Before you discover more issues, check the list here for some more currently known issues: #129 (comment) (you might as well try to reproduce them)

[bblazik]

I have also this problem. I thought that is compilation problem (some flags or whatever) but checked on target and everything works as should. It is strange because I can see whole call stack and break in proper line but can't see any variable. I wondering does it not a problem that I having a different start point. Still, I will try to figure it out, start maybe from gdb args.

[ivankravets]

The same for me with remote target. I've not seen this problem with previous VSCode versions. Maybe, they changed something.

Also, there is a big problem. The breakpoints are inserting immediately AFTER -exec-run. If they insert BEFORE, they are visible via (gdb) info b. This is a random issue.

For example,

1-gdb-set target-async on
2-environment-directory "..."
3-file-exec-and-symbols "...firmware.elf"
4-break-delete
source .pioinit
Running executable
5-exec-run
6-break-insert -f "C:\\Users\\User\...main.cpp:7"
i b
(no breakpoints)

@WebFreak001 do you have any ideas? Why does extension insert breakpoints after exec?

[WebFreak001]

uh vscode gives me the breakpoints after starting debugging iirc. Plus it needs to work afterwards to dynamically change breakpoints

[ivankravets]

@WebFreak001 Who does send a this command -exec-run?

[WebFreak001]

https://github.com/WebFreak001/code-debug/blob/master/src/gdb.ts#L106

[ivankravets]

Should we wait when autorun commands will be finished before running? https://github.com/WebFreak001/code-debug/blob/master/src/gdb.ts#L100

[WebFreak001]

it is.

[ivankravets]

https://github.com/WebFreak001/code-debug/blob/master/src/backend/mi2/mi2.ts#L737

I don't see any await/Promise.then(). So, this.miDebugger.start() will be run before end target (microcontroller) is ready for debugging. Am I right?

Normally, autorun with custom commands for embedded target requires 5-10sec depending on the device (flashing, halting, reseting).

[WebFreak001]

it isn't waiting for a response before starting, but it will send all commands in order so they should execute in that order according to the docs

[ivankravets]

Ok, you know that better. Do you have any ideas how to resolve the issue with breakpoints?

[WebFreak001]

of course that could be a feature improvement for example for flashing etc, if you want it you can make an issue and/or a PR, shouldn't be too hard, just adding a few things to package.json and to the 3 base debug servers

[WebFreak001]

no idea, would need to check the cause first, I have a feeling I will eventually work on this some more soon anyway