Support attach process on a remote target with remote/extended-remote mode

[fbs2016]

Feature Request

Now cpptools support attach local process, but don't support attach a process with remote target, both "target remote" and "target extended-remote" mode.

Not Pipe transport, the target don't support ssh connection, just like launch, we can connect to target with miDebuggerServerAddress and connect to gdbserver directly.
From gdb command, attach function just one command after target connection, like "attach xxx".

Refer to "Native Debug", it supports it now.

[fbs2016]

#4166

[fbs2016]

#78
#265

[sean-mcmanus]

Is this resolved with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.11.3 ? I'm not sure why there are 4 issues tracking the same issue. Let us know if something isn't fully resolved.

[fbs2016]

@sean-mcmanus Thanks. I try the new option "useExtendedRemote" it works for extended-remote launch. But it still has some issue with attach function.

[xisui-MSFT]

@fbs2016 Can you explain your scenario in more detail?

Based on your description, seem like your scenario is similar to:

1. Start gdbserver on the target, via "gdbserver : --multi"
2. In launch.json, set miDebuggerServerAddress to : and useExtendedRemote to true. If you don't specify process ID, a process picker will be shown. This is equivalent to gdb -> target extended-remote <hostname>:<port> -> attach <PID>.

This is supported though. What are the differences between this and your case?

[fbs2016]

@xisui-MSFT
Thanks
We have 2 ways to start gdbserver, gdbserver --multi or --once:port exeFile on remote target.

Next we want to attach the running process from VSC cpptools extention on local host. How to configure it? The processId in launch.json is process id on localhost but I want to attach the processs on remote target.

I try to create a configuration:
"processId":$ProcessIdOnRemoteTarget,
"useExtendedRemote": true, (try --once, it should be false, but it report err if processId and miDebuggerServerAddress used, extendedRemote should be true)
"miDebuggerServerAddress": "remoteTargetIP:gdbserverPort",
Then it report err, unable to start debugging ....

From gdb client, the command is simple just like you described : gdb-> target remote/extended-remote targetIp:gdbserverPort->attach pId in target

I can't find a right way to run it from VSC.

[xisui-MSFT]

@fbs2016 If you are using latest cpptools, you don't need to provide process ID anymore. A quick pick menu will be shown with processes on the target machine. Note that you'll need to use --multi for this since gdb need to connect once to fetch the processes, and request should be attach instead of launch.

A sample:

{
    "name": "Attach with GDB",
    "type": "cppdbg",
    "request": "attach",
    "program": "<program>",
    "MIMode": "gdb",
    "miDebuggerPath": "/usr/bin/gdb",
    "miDebuggerServerAddress": "<target>:<port>",
    "useExtendedRemote": true
}

[fbs2016]

@xisui-MSFT Thanks a lot.

1. I try the multi mode, it works between 2 Ubuntu host.

2. And I try on our embedded target, it failed and report err: Failed to make GDB connection: "Can not fetch data now".
   I guess that fetching the process id list failed, maybe due to no standard linux "ps" command on target or no worked connection created, and no any log in debug console.
   Does it support customized process id list input or just write the id in launch.json?
   BTW, the launch can work well on our target.

3. For others mode like "gdbserver --once targetIp:gdbserverPort exeFile ", I can't configure it between 2 Ubuntu host.

• I remove "useExtendedRemote": true as it's not gdbserver with muliti, but it show the quick pick menu with processes on local host not remote target.
• I add "useExtendedRemote": true, it show the processes list of remote target, but gdb connection failed as it try to connect target with "extended-remote"
• How to get the processes list of remote target? I don't think the list can be get from gdb connection as the gdb connect doesn't established when show the list.

[xisui-MSFT]

2. In extended remote mode, command <miDebuggerPath> -ex "target extended-remote <miDebuggerServerAddress>" -ex "info os processes" -batch is used to fetch remote processes, and ps is not used. Can you try if this command is supported on your target?

3. Because of the reason described above, --once won't work if you need to pick the process instead of providing in launch.json. (In attach mode, processId is the target process ID, so you can try provding it manually.)

As for ps, I think it works only with pipetransport, since it requires a way to connect to a terminal on the device (as opposed to gdbserver).

[fbs2016]

@xisui-MSFT
I think that the remote attach doesn't support gdbserver with "--once" mode if no processId option input . (To use useExtendedRemote as ture, try to start gdbserver with "--once --multi", it supports extended-remote connection and gdbserver stop listening after the first connection due to "--once" )
The following is my understanding of attach, am I right?
The attach create 2 gdb connections.
1 It create the first gdb connection to get process list by command "info os processes“, then close the connection
2 Then create the second connection to run "attach pid"
So the gdbserver will stop listening for any further connection when the first gdb connection closed see the definition of "--once" mode "Exit after the first connection has closed."

[fbs2016]

Try it on our target:
(gdb) info os processes
Can not fetch data now.

[xisui-MSFT]

The following is my understanding of attach, am I right?
The attach create 2 gdb connections.
1 It create the first gdb connection to get process list by command "info os processes“, then close the connection
2 Then create the second connection to run "attach pid"
So the gdbserver will stop listening for any further connection when the first gdb connection closed see the definition of "--once" mode "Exit after the first connection has closed."

Your understanding is correct. Looks like info os processes is not supported by your gdbserver. You may want to change your gdbserver so it can support that command, or provide PID manually.

When PID is provided manually, process picker will be skipped, and step (2) will be executed directly. And since we only connect once in this case, you can use --once.

[fbs2016]

@xisui-MSFT Thanks a lot, I will try to add new command customized to get the process list on my target.