How to apply multiple cwd entries for ssh debugging?

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

[GitMensch]

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].

[brownts]

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.