Skip to content

Incorrect file path locating by break point #442

Open

Description

@stlfatboy

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

Activity

  1. changed the title [-]Incorrect break point locating file path [/-] [+]Incorrect file path locating by break point[/+] on Sep 14, 2024
  2. GitMensch commented on Sep 14, 2024

    @GitMensch
    Collaborator

    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?

  3. stlfatboy commented on Sep 19, 2024

    @stlfatboy
    Author

    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

  4. GitMensch commented on Sep 19, 2024

    @GitMensch
    Collaborator

    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}"
                    }
                }
            }
        ]
    }
  5. stlfatboy commented on Sep 20, 2024

    @stlfatboy
    Author

    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.

  6. GitMensch commented on Sep 20, 2024

    @GitMensch
    Collaborator

    Where dos that cygdrive comes from?

  7. stlfatboy commented on Sep 23, 2024

    @stlfatboy
    Author

    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

  8. GitMensch commented on Sep 23, 2024

    @GitMensch
    Collaborator

    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-

  9. stlfatboy commented on Sep 26, 2024

    @stlfatboy
    Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions