Support relative paths in debug symbol information

[sbalabanov-zz]

When Bazel produces go binary in debug mode, it strips out absolute paths from source file paths to make artifacts deterministic. This means, though, that VS Code is unable to correctly set breakpoints for such a binary, and in general, unable to match sources in the binary being debugged with the local sources. This all because vscode-go plugin expects go binary to contain absolute paths.

The plugin has support for "remotePath" property but it can't be left empty to strip out absolute path, so a separate property is introduced "useRelativePaths"; if set to true the plugin would use relative source file path to match with debugging symbol information.

Another property 'pathSeparator' allows to specify the separator type (windows \ or unix /). This simplifies remote debugging of binaries compiled for the platform not identical to the one which runs VS Code. Default value 'auto' resembles the current behavior where remote path separator is inferred from remotePath parameter if one is specified.

This change also refactors a potentially dangerous handling of remotePath parameter - instead of string replace it uses a safer variant of prefix match.

[msftclas]

All CLA requirements met.

[sbalabanov-zz]

any update on this one?

[ramya-rao-a]

Hey @sbalabanov-zz,

My apologies for the late response.

We have made some improvements in the way the path separators are used and mapped, but also realize the need to respect relative paths. We want to explore a few other alternatives before resorting to adding more fields/properties to the debug configuration as being done in this PR.

Please take a look at golang/vscode-go#45 where @quoctruong has shared the current state of things and potential improvements. There is a linked PR that you can check out as well. We would appreciate your input there.

As for this PR, we will have to close it as we are currently in the midst of a repo move, see We are moving section in our readme for more details. At the moment, we are not accepting any PR unless it is related to the move or critical bug fixes.

Thanks for your efforts here and we hope to see you engage in the discussion in golang/vscode-go#45