posix.resolve windows setBreakpoints wrong path

[mmitkevich]

Here you rely on correct behavior of posix.resolve and posix.relative

code-debug/src/mibase.ts

Line 227 in 606a25b

path = relative(this.trimCWD.replace(/\\/g, "/"), path.replace(/\\/g, "/"));

But it is not the case on Windows
as result paths like /a/b/C:\my\dir/and/so/on are sent with setBreakpoints

Probably it could be rewritten with some replaces without posix. For my purposes I had to patch this place but my solution is too hacky (just replace C:| with nothing)

possibly dup of #171

[WebFreak001]

try again now pls, I released a new version

[HaronK]

I just tried a new version. It doesn't show error message box anymore but it still doesn't work and there is a new message in Debug Console:

No source file named C.

So there should be some other issue.
Is it possible to install this extension in VSCode from the local source code to test it?

UPD.
With showDevDebugOutput flag enabled I got a bit more information:

GDB -> App: {"token":6,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"log","content":"No source file named C.\n"}]}
No source file named C.

[WebFreak001]

@HaronK uhh I kind of assumed you did that with the previous PR. Well I thought after reviewing it that it is a needed change anyway so it shouldn't be so bad.

You can just clone the repository, run npm install and then tsc -w. You can then start the extension using the debug panel inside vscode to install it for a test instance

[AndrewMcClory]

I too, have begun receiving the "No source file named C." message as of version 0.23. Prior to this recent version, my breakpoints were working properly.

[pbruenn]

I can confirm this issue with VSC running on Windows 10 remote debugging a FreeBSD 12.0 over ssh/gdb.
The issue appeared with 0.23 and can be fixed by reverting commit 806cd35.

[WebFreak001]

so did it detect local files in vscode fine before with SSH on windows to some unix host?

[pbruenn]

Yes 0.22 was working fine for me. I remember issues similar to #171, but I think I solved them by fixing cwd.
My launch.json looks like this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "debug-on-remote",
            "type": "gdb",
            "request": "launch",
            "target": "main.bin",
            "cwd": "${workspaceFolder}",
            "ssh": {
                "host": "192.168.0.1",
                "user": "pbruenn",
                "cwd": "/usr/home/pbruenn/${workspaceFolderBasename}",
                "password": "1",
                "forwardX11": false,
            }
        },
    ]
}

[AndrewMcClory]

Ditto everything said by @pbruenn . I too was running VSC on Windows 10, and was detecting local files fine prior to 0.23.

[garyng]

Same here.

launch.json:

{
    "version": "0.2.0",
    "configurations": [     
        {
            "type": "gdb",
            "request": "launch",
            "name": "Launch",
            "target": "bin",
            "arguments": "-m",
            "cwd": "${workspaceRoot}",
            "valuesFormatting": "parseText",
            "ssh": {
                "forwardX11": false,
                "host": "ip",
                "cwd": "/usr/xxx/yyy/",
                "password": "1",
                "user": "1",
            }
        }

    ]
}

extension info:

Name: Native Debug
Id: webfreak.debug
Description: GDB, LLDB & Mago-MI Debugger support for VSCode
Version: 0.23.0
Publisher: WebFreak
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=webfreak.debug

vscode info:

Version: 1.32.3 (user setup)
Commit: a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4
Date: 2019-03-14T23:43:35.476Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 6.1.7601

[AndrewMcClory]

@WebFreak001 Thank you so much for fixing this. The breakpoints work again. This is really a wonderful and useful extension.