WebFreak001 / code-debug

Native debugging for VSCode
The Unlicense
410 stars 115 forks source link

Incorrect file path locating by break point #442

Open stlfatboy opened 2 months ago

stlfatboy commented 2 months ago

Using ssh gdb(13.1), triggering break point ok but with a wrong path

launch.json:

{
    "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": {
                    "${workspaceFolder}": "${workspaceFolder}"
                }
            }
        }
    ]
}

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

It should be: F:\project\src\func\main.cpp

image image

GitMensch commented 2 months ago

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

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?

updated original post

GitMensch commented 2 months ago

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

{
    "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 commented 2 months ago

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

{
    "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}"
                }
            }
        }
    ]
}

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

Where dos that cygdrive comes from?

stlfatboy commented 2 months ago

Where dos that cygdrive comes from?

I have no idea. maybe from vscode itself or cmake pulgin? the cross-compiler I'm using is based on cygwin

GitMensch commented 2 months ago

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

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/...)