You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I add a break point at IDE side(by click at line number)
The popup file's path: \cygdrive\f\project\build\Cygwin_RelWithDebInfo\src\func\F:\project\src\func\main.cpp
There's only a blurry screenshot... So: what is the scenario, what the launch config, how was the breakpoint created, what path is wrong and how should it be like?
There's only a blurry screenshot... So: what is the scenario, what the launch config, how was the breakpoint created, what path is wrong and how should it be like?
I see , the scenario is an ssh launch config from a Windows environment with the workspaceFolder being F:\project, connecting to a cygwin server "/home/debug/". I'm a bit confused that setting the breakpoint actually did work, but the way back is only possible when configuring the correct sourceFileMap. It is always "remote path" to "local (ide) path", so the correct setup seems to be something like
I see , the scenario is an ssh launch config from a Windows environment with the workspaceFolder being F:\project, connecting to a cygwin server "/home/debug/". I'm a bit confused that setting the breakpoint actually did work, but the way back is only possible when configuring the correct sourceFileMap. It is always "remote path" to "local (ide) path", so the correct setup seems to be something like
I'm using cross-compiler from windows to build linux binary.
the remote server is actually a normal linux server running debian.
if I changed the launch.json according to your instruction, gdb will complain below and hit no break point No source file named /cygdrive/f/project/build/Cygwin_RelWithDebInfo/src/func/main.cpp.
ah, an edit... it definitely isn't because of vscode or cmake as the source paths for the debugger are inserted by the compiler - a cross-compiler that's cygwin based does make much more sense.
It is very likely that everything works once you've switch to use GDB from that environment as well.
As an alternative you can try to use the old config with a GDB option, possibly in autorun: set substitute-path \\cygdrive\\f\\project\\build\\Cygwin_RelWithDebInfo\\src f:\\project\\src - or patch the wrong debug path after generating the files-
ah, an edit... it definitely isn't because of vscode or cmake as the source paths for the debugger are inserted by the compiler - a cross-compiler that's cygwin based does make much more sense. It is very likely that everything works once you've switch to use GDB from that environment as well.
As an alternative you can try to use the old config with a GDB option, possibly in autorun: set substitute-path \\cygdrive\\f\\project\\build\\Cygwin_RelWithDebInfo\\src f:\\project\\src - or patch the wrong debug path after generating the files-
debug console output:
Thread 1 "func" hit Breakpoint 1, main (argc=<optimized out>, argv=0x7fffffffeb98) at F:/project/src/func/main.cpp:120
120 F:/project/src/func/main.cpp: No such file or directory.
gdb seems working fine with the source file path(without cygdrive/...)
Activity
[-]Incorrect break point locating file path [/-][+]Incorrect file path locating by break point[/+]GitMensch commentedon Sep 14, 2024
There's only a blurry screenshot... So: what is the scenario, what the launch config, how was the breakpoint created, what path is wrong and how should it be like?
stlfatboy commentedon Sep 19, 2024
updated original post
GitMensch commentedon Sep 19, 2024
I see , the scenario is an ssh launch config from a Windows environment with the workspaceFolder being
F:\project, connecting to a cygwin server"/home/debug/". I'm a bit confused that setting the breakpoint actually did work, but the way back is only possible when configuring the correctsourceFileMap. It is always "remote path" to "local (ide) path", so the correct setup seems to be something like{ "version": "0.2.0", "configurations": [ { "type": "gdb", "request": "launch", "name": "Launch (SSH)", "target": "func", "cwd": "${workspaceFolder}", "ssh": { "host": "192.168.1.1", "cwd": "/home/debug/", "password": "root", "user": "root", "sourceFileMap": { "\\cygdrive\\f\\project\\build\\Cygwin_RelWithDebInfo": "${workspaceFolder}" } } } ] }stlfatboy commentedon Sep 20, 2024
I'm using cross-compiler from windows to build linux binary.
the remote server is actually a normal linux server running debian.
if I changed the launch.json according to your instruction, gdb will complain below and hit no break point
No source file named /cygdrive/f/project/build/Cygwin_RelWithDebInfo/src/func/main.cpp.GitMensch commentedon Sep 20, 2024
Where dos that cygdrive comes from?
stlfatboy commentedon Sep 23, 2024
I have no idea.
maybe from vscode itself or cmake pulgin?
the cross-compiler I'm using is based on cygwin
GitMensch commentedon Sep 23, 2024
ah, an edit... it definitely isn't because of vscode or cmake as the source paths for the debugger are inserted by the compiler - a cross-compiler that's cygwin based does make much more sense.
It is very likely that everything works once you've switch to use GDB from that environment as well.
As an alternative you can try to use the old config with a GDB option, possibly in autorun:
set substitute-path \\cygdrive\\f\\project\\build\\Cygwin_RelWithDebInfo\\src f:\\project\\src- or patch the wrong debug path after generating the files-stlfatboy commentedon Sep 26, 2024
debug console output:
gdb seems working fine with the source file path(without cygdrive/...)