Skip to content

How to apply multiple cwd entries for ssh debugging? #298

Closed

Description

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

Activity

  1. WebFreak001 commented on Nov 10, 2021

    @WebFreak001
    Owner

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

  2. GitMensch commented on Nov 10, 2021

    @GitMensch
    CollaboratorAuthor

    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"
    },
  3. brownts commented on Nov 12, 2021

    @brownts
    Collaborator

    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.

  4. GitMensch commented on Nov 12, 2021

    @GitMensch
    CollaboratorAuthor

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

  5. brownts commented on Nov 18, 2021

    @brownts
    Collaborator

    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.

  6. self-assigned this
    on Mar 4, 2022
  7. GitMensch commented on Mar 4, 2022

    @GitMensch
    CollaboratorAuthor

    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.

  8. added 6 commits that reference this issue on Mar 4, 2022
    f0feba3
    64ce3b2
    bf8974b
    fcb1c02
    8d1460f
    ecb2da4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions