Progress picker not showing the remote progresses

[xisui-MSFT]

Bug type: Debugger

Describe the bug

• OS and Version: Windows 10, 19044.1348
• VS Code Version: 1.62.3
• C/C++ Extension Version: 1.7.1
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is. When specifying a remote address in launch.json, like "miDebuggerServerAddress": "192.168.35.2:6000", and setting requestType to attach, the progress picker shown is for local processes. We need the remote processes instead (with a command like info os processes for gdb).

To Reproduce Steps to reproduce the behavior:

1. Setup a GDB server on a remote machine
2. Add a local launch file, that specifies miDebuggerServerAddress, with requestType set to attach.
3. Start debugging. Expecting to see a progress picker for a remote machine,

[WardenGnaw]

For now, the remote process picker does not work with miDebugServerAddress, you will need to use pipeTransport for the extension to communicate with the machine.

[xisui-MSFT]

@WardenGnaw Looks like pipeTransport requires a pipe program https://code.visualstudio.com/docs/cpp/pipe-transport, but we are using GDB on the local machine. Sample command:

gdb \
<binary-on-host-with debug-info\> \
   -ex "set sysroot ${SYSROOT}" \
   -ex "set solib-search-path ${SYSROOT}" \
   -ex "set debug-file-directory ${SYSROOT}" \
   -ex "target extended-remote 192.168.35.2:6000" \
   -ex "info os processes"

This command (info os processes) prints the processes on the remote machine. Also I think it's just a gdb server on the remote machine so ssh probably won't work.

Any suggestions?

[WardenGnaw]

Unfortunately, you will have to supply processId manually.

The VS Code extension does not talk to GDB directly and the process picker can only work with a connection to the terminal so it can use ps to get process information.

[xisui-MSFT]

Is it possible to modify MIEngine somehow to have an option to get processes via GDB instead?

[WardenGnaw]

Here is the code for the local process picker and the remote process picker. At this phase, we are still in VS Code, resolving the launch.json configuration before even starting debugging, aka OpenDebugAD7/MIEngine has not started yet.

You could try to add another picker that tries to communicate with the gdb using the fields in launch.json to attempt to do a process listing with gdb, but you wont be able to re-use the connection that exists in MIEngine.

[xisui-MSFT]

@WardenGnaw Sorry for replying late. We are also investigating how to do debugging in this case. And for us, looks like attach is required to be after gdb connects (extended-remote): https://sourceware.org/gdb/onlinedocs/gdb/Connecting.html. While I didn't find way with currently supported scenarios, I'm wondering if you have any suggestions, or if your team have any plan to support extended-remote?

[WardenGnaw]

Took a look into this and tried out a scenario by hand (Without MIEngine).

1. Started up gdbserver via gdbserver --multi :12345
2. Connected to gdbserver via

gdb
target extended-remote :12345

3. Get process listing via info os processes

---

Currently have two possible solutions to this issue:

Scenario A: Talk to gdbserver twice

In a VS Code Extension, create a new handler ${gdbServerRemoteProcessPicker} that uses miDebugServerAddress to figure out how to connect to the gdbserver. Write a simple process exec to gdb that sends the similar commands above, get the process listing and provides it to the user similar to how we do our current process pickers.

Scenario B: Implement in MIEngine

In the launch.json, we have a custom string or pattern that MIEngine recognizes that the processId needs to come from gdbserver e.g. processId: "GDB-SERVER-PROCESS-PICKER".

Then OpenDebugAD7 would understand that it would need to launch gdbserver in a special way to connect to the remote machine and ask for its processes.

These processes would come through via a new AD7Event (AD7ProcessListingEvent).

Then we would need to create a custom DebugAdapterProtocol for this scenario where the VS Code client can receive a process listing request with all of the processes in info os processes, show the process picker dialog, and send a response with the one the user selected.

---

[xisui-MSFT]

@WardenGnaw Yes we are able to get a list of processes, and we decide to proceed with option A for now. But I have another question... Even if we provide PID manually, looks like we still can't use cppdbg to debug, because processId isn't compatible with either launch mode or miDebuggerServerAddress under attach mode...

[WardenGnaw]

That is due to https://github.com/microsoft/MIEngine/blob/c2ed23eb1cb5575659e756ba9af9f42d52f71254/src/OpenDebugAD7/AD7DebugSession.cs#L1145-L1149

We have never supported remote attach via miDebuggerServerAddress.

[xisui-MSFT]

@WardenGnaw So any suggestions for us on this conflict...?

[WardenGnaw]

Remove that check but we will see more errors if the remote pid does not exist.

Scenario B is better since we know within MIEngine that the process exists instead of taking in a random process id from launch.json.

[xisui-MSFT]

@WardenGnaw So we will need to implement option B in MIEngine? While I would ask our team about schedules, can you provide some related code pointers?

[WardenGnaw]

You can go with option A, but you will need to remove that check in MIEngine since we never supported this scenario before.

I was just mentioning the downside with A is that we do not have any good way to validate that the process exists.

[sean-mcmanus]

Is this issue resolved with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.11.4 ?