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?