[Feature Request] Change Attach to Process to not require a program name by inferring it.

[chibicitiberiu]

Currently, in order to attach to a process, I need to provide the following fields in my launch.json:

{
    "name" : "Attach (gdb)",
    "type" : "cppdbg",
    "request" : "attach"
    "program" : "${workspaceFolder}/path/to/program",
    "processId" : "${command:pickProcess}",
    "MIMode" : "gdb"
}

In my tests, it seems that the program field is validated (i.e. the executable exists, it is a valid executable), but it is completely ignored when debugging. I can set "program" = "/bin/bash" and attach to any process I want. But if I set "program" = "non existent file", I get a launch error that the program doesn't exist.

So why do I need to provide a path to the executable, when it is not needed?

Of course, it would be nice if ${command:pickProcess} would use this field to filter the processes, but it doesn't. Even then, it should be optional.

[sean-mcmanus]

On Linux, what I've experienced is that if the program doesn't match the process that is attached to, then the symbols and breakpoints won't be hit, so it's useless. I agree it seems odd why the field can't be auto-populated based on the PID ("process" is not needed when using the cppvsdbg debugger on Windows). Maybe @pieandcakes knows more.

[pieandcakes]

We send it to gdb to tell it where to load symbols from. if you do /bin/bash does gdb load the symbols correctly for the process you are debugging? We can look at removing it if it truly isn't needed.

[chibicitiberiu]

@pieandcakes I tested, and yes, you are right. Symbols aren't loaded if I set "program" : "/bin/bash".

If I start gdb from command line with gdb --pid <pid>, the symbols are loaded just fine, so I still say that this field shouln't be necessary. I don't understand why it doesn't load them when started through cpptools.

[pieandcakes]

@chibicitiberiu We use gdb in mi mode. I don't know if this makes a difference to how gdb actually operates but I suspect this is the reason why we're requiring the program field.

If you add this block to your launch.json, you can see the commands we send to gdb and the responses we get.

"logging": { "engineLogging": true }

[rknuus]

+1

If the program name cannot be determined automatically please consider to provide an option like ${command.pickFile} and leave it up to the user to pick the right executable.

[neumann-d]

+1

The program path is already shown in the process list where you pick the process to attach. Shouldn't it be possible to just grab it from there? Maybe it needs a bit parsing to stop at the program arguments.

[pieandcakes]

@neumann-d I'll change this to a feature request

[batesj]

+1

Is there any workaround using tasks/commands to somehow automate the program variable replacement?

[mic-e]

@batesj:
Yes. As a workaround, you can use the beauty of procfs:

            "program": "/proc/${command:pickProcess}/exe",
            "processId": "${command:pickProcess}"