Feature request: have an `xcdebug` equivalent for lldb-dap

[JDevlieghere]

On macOS, xcdebug allows you to start a debug session in Xcode from the command line:

xcdebug [options] <command> [args ...]
Starts a 'process-based' debugging session: Spawns the given command with
the given arguments in the current terminal and asks the most recently used
Xcode window to attach to it (opens a new temporary debugging-only window if
no windows are open).

I work almost exclusively in the terminal, but I’d love to take advantage of an IDE for debugging. I wish there were something similar for lldb-dap and VS Code. However, I’m not sure this would really fit within lldb-dap, as the DAP implementation is, by design, agnostic of the IDE or editor that uses it. For this to work, the binary (whether lldb-dap or something else) would need to know which program to launch and how.

[vogelsgesang]

I am having a similar, terminal-focused workflow.
For CodeLLDB (the other LLDB-based VS-Code debugger extension), I am using this script.

The user-facing flow is:

1. I run the script as vscode-debug.sh my-binary --foo bar /som/other/arg
2. It will print a vscode:// URL. Upon clicking on this URL, the last used VS-Code window will be focused and I will be taken to a newly started debugging session

Under the hood, it works by:

• spawning a lldb-server with the provided command (lldb-server gdbserver :$PORT -- $@), listening on a given port
• printing a special vscode://vadimcn.vscode-lldb/launch/config?<launchConfig> URL to the console

This vscode-URL will focus the most recently used VSCode window. The CodeLLDB extension is handling the vadimcn.vscode-lldb/launch/config request and launching a debug session with the provided ad-hoc config.

The provided ad-hoc config contains processCreateCommands\":[\"gdb-remote 127.0.0.1:$PORT\"] which instructs LLDB to connect back to the lldb-server which we just launched.

See this documentation for the URL schemes supported by CodeLLDB.

If we want to enable the same workflow also in lldb-dap, we would have to register our own UriHandler with VS-Code

[vogelsgesang]

If you are trying to debug locally you might also be able to directly pass the vscode:// URL to xdg-open or code --open-url.

For debugging remotely (via SSH or within a container), this workflow used to be broken in the past (see microsoft/vscode-remote-release#4260), but this might have been fixed recently (see microsoft/vscode@521c6bc).

[vogelsgesang]

With the recent PR adding basic URL support, do we maybe want to integrate the script's functionality natively into one of LLDB's tools? E.g., we could add an --lldb-dap-uri option to lldb-server to instruct lldb-server to print the lldb-dap URI. Not sure if we are fine with having any VSCode/lldb-dap specific functionality in lldb-server, though.

Also, personally I would love to keep stdin/stdout/stderr in the original lldb-server console and not have it forwarded to the debugger's window. Not sure if lldb-server already provides a flag for that?

[JDevlieghere]

Doing that in the debug stub seems like the wrong place. I originally suggested doing this in lldb-dap because it should already know how to do a reverse connect for running your binary in the terminal. I was hoping we could reuse some of that logic.

[vogelsgesang]

I originally suggested doing this in lldb-dap

I must have missed that suggestion. I interpreted your "I’m not sure this would really fit within lldb-dap" in the first comment as a suggestion against doing this in lldb-dap. Did I misinterpret that? Or did I miss some other communication in the meantime (Discourcse, other Github issues, ...)?

should already know how to do a reverse connect for running your binary in the terminal. I was hoping we could reuse some of that logic.

Not sure which exact logic you are referring to. Could you point me to a source code file / function you had in mind?

[JDevlieghere]

This came up in several conversations at the LLVM Developer meeting. The thing that kept coming up is that users often want to debug different invocations and are used to prefixing their command with lldb -- and they'd like something similar to that.