How to apply multiple cwd entries for ssh debugging?

[GitMensch]

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

[WebFreak001]

multiple cwd? how would that work or what would that do? you can only start an executable in one set working directory

[GitMensch]

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"
},

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

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

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]

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.