================
@@ -0,0 +1,42 @@
+import * as path from "path";
+import * as vscode from "vscode";
+import { createProcessTree } from "../process-tree";
+
+interface ProcessQuickPick extends vscode.QuickPickItem {
+ processId: number;
+}
+
+/**
+ * Prompts the user to select a running process.
+ *
+ * The return value must be a string so that it is compatible with VS Code's
+ * string substitution infrastructure. The value will eventually be converted
+ * to a number by the debug configuration provider.
+ *
+ * @returns The pid of the process as a string or undefined if cancelled.
+ */
+export async function pickProcess(): Promise<string | undefined> {
----------------
vogelsgesang wrote:
afaik, this function receives the unresolved configuration as its first
parameter. As such, we should have access to the `program` argument from your
snippet
```javascript
{
"type": "lldb-dap",
"request": "attach",
"name": "Attach to PID",
"program": "/tmp/a.out",
"pid": "${command:PickProcess}"
}
```
Should we inspect that `program` argument and only show PIDs which are running
`/tmp/a.out` in that case?
Afaict, picking a PID for belonging to a different executable file would lead
to an error in lldb-dap, anyway? As such, I think we should probably not even
offer that as an option to the user.
(Side-note: Afaict, this would also give you access to `debugAdapterExecutable`
in case you would indeed want to call into the `lldb-dap` binary instead of
calling `ps` etc.)
https://github.com/llvm/llvm-project/pull/128943
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
