Support attaching to a process by name/pattern for remote attach (useExtendedRemote / pipeTransport #14682

Feature Request

Feature request

When attaching to a process on a remote target, the process to attach to always has to be selected manually from the process picker. Please allow the configuration to name the process, so that the attach can be fully automated.

Why the current behaviour is a problem

I generate launch.json files automatically from build metadata (the Yocto Project's devtool ide-sdk, which creates VS Code configurations for cross-debugging an embedded target over gdbserver). Each generated configuration is bound to exactly one executable: program, sourceFileMap, additionalSOLibSearchPath and the setupCommands (sysroot, pretty printers) all belong to that one binary.

The PID cannot be put into the generated configuration, because it changes on every boot and every restart of the service. So the only option today is the picker, which lists every process on the device. That is unfortunate for two reasons:

• The user has to pick the right process manually on every debug session, although the configuration already knows which executable it is for.
• Picking anything else silently produces a session with mismatched symbols and source mappings.

The extension already does this for local attach

Extension/src/Debugger/configurationProvider.ts:

// If program is specified and not remote attach, try to find the matching process by name
if (config.program && !config.pipeTransport && !config.useExtendedRemote) {
    processId = await this.findProcessByProgramName(config.program, token);
}

findProcessByProgramName() filters the process list by the basename of program and attaches directly when exactly one process matches. The remote cases are excluded, apparently because the function uses NativeAttachItemsProviderFactory.Get(), which enumerates local processes only.

For remote there is already an equivalent process source: RemoteAttachPicker.getRemoteProcessesExtendedRemote() (info os processes via target extended-remote) and getRemoteOSAndProcesses() for pipeTransport.

Proposal

When request: attach and no processId is given, apply a name/pattern match to the remote process list as well, and only fall back to the picker if the match is not unique:

• match count 1 → attach directly
• match count > 1 → show the picker, prefiltered to the matches
• match count 0 → show the full picker (or report an error)

Two possible shapes, either would solve it:

1. Simply extend the existing program-based matching to the remote paths.
2. Add an explicit property, e.g. processFilter (regular expression), matched against the fields already shown in the picker. This is more flexible for the remote case, because for useExtendedRemote the AttachItem.label is not a bare process name but the user plus the whole command line, built in parseProcessesFromInfoOsProcesses():

processes.push({ label: userCommand, id, description: id });

so a regex like /usr/bin/my-daemon matches reliably where a basename comparison would not.

An example of the configuration I would like to generate:

{
    "name": "attach my-daemon",
    "type": "cppdbg",
    "request": "attach",
    "program": "/path/on/build/host/to/unstripped/my-daemon",
    "MIMode": "gdb",
    "miDebuggerPath": "/path/to/aarch64-poky-linux-gdb",
    "miDebuggerServerAddress": "192.168.7.2:1234",
    "useExtendedRemote": true,
    "processFilter": "/usr/bin/my-daemon"
}

Additional benefit

request: attach also detaches from the process instead of killing it when the debug session is stopped, unlike request: launch, which is what #4166 is about. Being able to use request: attach without a manual picker step would make that the natural configuration for attaching to a running service on a remote target.

Environment

• C/C++ extension version: 1.32.2
• Target: aarch64 Linux (QEMU), gdbserver --multi, connected via miDebuggerServerAddress + useExtendedRemote

Related

• Support attach process on a remote target with remote/extended-remote mode #9505 — added useExtendedRemote (thanks, it works well)
• [gdbserver] Detach when stopping debugging when using gdbserver #4166 — detach instead of kill when stopping a gdbserver session