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
{{ message }}
Repository navigation
How to apply multiple cwd entries for ssh debugging? #298
Currently there is only one cwd from the launch config mapped to one from ssh.cwd.
Commonly multiple ones are needed...
I suggest to keep the current ssh.cwd but mark it as deprecated (this way people's configuration doesn't break after an update but have the change to adjust and not use that when creating a new setup) and add a new configuration ssh.pathSubstitutions (map paths between the host machine and the local one; the MS extension names that sourceFileMap so we may use that, too - but it should be placed under ssh to keep the correct scope).
It is enough to have one cwd - but it should be possible to have multiple path translations:
To give my example:
"ssh.pathSubstitutions": {
// application installed on the machine (could also come from the os distribution)"/opt/apps/install/app1": "X:/progs/app1",
// libraries installed on the machine that the application is linked against"/opt/apps/install/app2": "X:/lib/app2",
"/opt/apps/install/app3": "X:/lib/app3",
// source for shared objects dynamically loaded by the app"/opt/${config:my.app}/src": "${workspaceFolder:src}", // that's the "real" cwd// source for shared objects loaded by the modules"/opt/lib1": "X:/common/lib1",
"/opt/lib2": "X:/common/lib2"
},
Is there a reason that the regular pathSubstitutions configuration wouldn't meet those needs? The MS sourceFileMap is the equivalent of the pathSubstitutions configuration in this extension. I don't believe there is a special sourceFileMap configuration for the pipeTransport in the MS extension.
Is there a reason that the regular pathSubstitutions configuration wouldn't meet those needs?
That's a good question which answer is necessary to understand, so "let's doc a bit".
Yes - there is a reason. The regular pathSubstitutions are given to GDB and tell it how to relate the source references in the debug info to the actual files on the machine (so GDB can find them).
If you use GDB remote debugging, the debug info needs to either be on the host machine or is copied over the connection, GDB then maps the source entries to the host machine where it runs on. You only need the source on the host and need the debug symbols either on the host or have a connection where GDB can download them as-needed [or you have a debugserver but then GDB will download it from there].
With the ssh options GDB runs on the ssh-target, it may still need path substitutions on the ssh-target to find the source there. ssh.pathSubstitutions will then map what GDB has as file reference on the ssh-target machine to the place where vscode runs.
Debug info is only needed on the host (which may save a lot of bandwith), source files are needed on both the host and the ssh-target. [again: GDB, now running on the ssh-target may get those from a debugserver; and as a special case GDB may only run on the ssh-target but is connected to another machine itself so the ssh-target may not even run the inferior; and yes, that's sometimes needed because the only way you get to the "real" target is to use a ssh connection to kind of a proxy].
Thanks for the follow-up. I use GDB in many different configurations, although I haven't had a need yet to use it over SSH. I guess there is an additional level of indirection that needs to be accounted for when running in that environment.
I guess there is an additional level of indirection that needs to be accounted for when running in that environment.
Yes. pathSubstitutions are for the running GDB on the remote to find the sources, the new ssh.sourceFileMap will be taken into account to map directories that are found and named by GDB to local ones (that vscode opens). @WebFreak001 already did the hard work for the mapping (necessary in both directions, from local to remote mostly when setting breakpoints via ui [setting breakpoints via console will need the GDB view of the paths]).
I'm working on this now during wait for the decision about the changed attach #241.
Activity
WebFreak001 commentedon Nov 10, 2021
multiple cwd? how would that work or what would that do? you can only start an executable in one set working directory
GitMensch commentedon Nov 10, 2021
It is enough to have one cwd - but it should be possible to have multiple path translations:
To give my example:
brownts commentedon Nov 12, 2021
Is there a reason that the regular
pathSubstitutionsconfiguration wouldn't meet those needs? The MSsourceFileMapis the equivalent of thepathSubstitutionsconfiguration in this extension. I don't believe there is a specialsourceFileMapconfiguration for thepipeTransportin the MS extension.GitMensch commentedon Nov 12, 2021
That's a good question which answer is necessary to understand, so "let's doc a bit".
Yes - there is a reason. The regular
pathSubstitutionsare given to GDB and tell it how to relate the source references in the debug info to the actual files on the machine (so GDB can find them).If you use GDB remote debugging, the debug info needs to either be on the host machine or is copied over the connection, GDB then maps the source entries to the host machine where it runs on. You only need the source on the host and need the debug symbols either on the host or have a connection where GDB can download them as-needed [or you have a debugserver but then GDB will download it from there].
With the
sshoptions GDB runs on the ssh-target, it may still need path substitutions on the ssh-target to find the source there.ssh.pathSubstitutionswill then map what GDB has as file reference on the ssh-target machine to the place where vscode runs.Debug info is only needed on the host (which may save a lot of bandwith), source files are needed on both the host and the ssh-target. [again: GDB, now running on the ssh-target may get those from a debugserver; and as a special case GDB may only run on the ssh-target but is connected to another machine itself so the ssh-target may not even run the inferior; and yes, that's sometimes needed because the only way you get to the "real" target is to use a ssh connection to kind of a proxy].
brownts commentedon Nov 18, 2021
Thanks for the follow-up. I use GDB in many different configurations, although I haven't had a need yet to use it over SSH. I guess there is an additional level of indirection that needs to be accounted for when running in that environment.
GitMensch commentedon Mar 4, 2022
Yes.
pathSubstitutionsare for the running GDB on the remote to find the sources, the newssh.sourceFileMapwill be taken into account to map directories that are found and named by GDB to local ones (that vscode opens).@WebFreak001 already did the hard work for the mapping (necessary in both directions, from local to remote mostly when setting breakpoints via ui [setting breakpoints via console will need the GDB view of the paths]).
I'm working on this now during wait for the decision about the changed attach #241.
new `ssh.sourceFileMap` configuration for multiple substitutions
new `ssh.sourceFileMap` configuration for multiple substitutions
new `ssh.sourceFileMap` configuration for multiple substitutions
new `ssh.sourceFileMap` configuration for multiple substitutions
new `ssh.sourceFileMap` configuration for multiple substitutions
new `ssh.sourceFileMap` configuration for multiple substitutions