This allows other debugger extensions to leverage the `lldb-dap`
extension's settings and logic (e.g. "Server Mode").
Other debugger extensions can invoke these commands to resolve
configuration, create adapter descriptor, and get the `lldb-dap` process
for state tracking, additional interaction, and telemetry.
VS Code commands added:
* `lldb-dap.resolveDebugConfiguration`
* `lldb-dap.resolveDebugConfigurationWithSubstitutedVariables`
* `lldb-dap.createDebugAdapterDescriptor`
* `lldb-dap.getServerProcess`
# Problem
When the user changes lldb-dap's arguments (e.g. path), there is a race
condition, where the new lldb-dap process could be started first and
have set the extension's `serverProcess` and `serverInfo` according to
the new process, while the old lldb-dap process exits later and wipes
out these two fields.
Consequences:
1. This causes `getServerProcess()` to return `undefined` when it should
return the new process.
2. This also causes wrong behavior when starting the next debug session
that a new lldb-dap process will be started and the old not reused nor
killed.
# Fix
When wiping the two fields, check if `serverProcess` equals to the
process captured by the handler. If they equal, wipe the fields. If not,
then the fields have already been updated (either new process has
started, or the fields were already wiped out by another handler), and
so the wiping should be skipped.
- ~Add `winston` dependency (MIT license) to handle logging setup~
- Have an `LogOutputChannel` to log user facing information, errors,
warnings
- Write a debug session logs under the provided `logUri` to capture
further diagnostics when the `lldb-dap.captureSessionLogs` setting is
enabled. *Note* the `lldb-dap.log-path` setting takes precedence when
set
Issue: #146880
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
- Allow running when no workspace folder is present, and do not override
the `cwd` set in the launch configuration
- Support getting configuration from workspace file
Fixes#142469
if the `cwd` option is empty this means the adapter is created in the
home folder.
Any relative file saved is in the home folder. The files should be
relative to the current workspace folder.
Small assortment of changes to the modules UI after trying it out:
- Print the load address as hexadecimal.
- Remove spurious space before colon.
- Drop "Module" prefix from tooltip title.
- Capitalize bold list items.
This creates a very basic module explorer for tracking and displaying
loaded modules, reported by lldb-dap for the active debug session.
This includes a basic session tracker that we can use to observe the
debug session and collect specific information for additional
visualizations in the lldb-dap ext.
Here is a screenshot of the current visualization in the tree view.
There is some unfortunate wrapping of the path, but it shows the basic
support that could be extended in the future.
<img width="1759" alt="Screenshot 2025-05-07 at 2 52 50 PM"
src="https://github.com/user-attachments/assets/588baa2f-61d5-4434-8692-b1d0cce42875"
/>
This adds support for loading user level defaults in VSCode. The
defaults are stored as basic settings that are loaded when the debug
configuration is resolved. Not all settings are currently supported, I
limited it to settings that would likely apply across multiple
launch.json configurations.
This should resolve#134564
Added a new setting called `lldb-dap.arguments` and a debug
configuration attribute called `debugAdapterArgs` that can be used to
set the arguments used to launch the debug adapter. Right now this is
mostly useful for debugging purposes to add the `--wait-for-debugger`
option to lldb-dap.
Additionally, the extension will now check for a changed lldb-dap
executable or arguments when launching a debug session in server mode. I
had to add a new `DebugConfigurationProvider` to do this because VSCode
will show an unhelpful error modal when the
`DebugAdapterDescriptorFactory` returns `undefined`.
In order to facilitate this, I had to add two new properties to the
launch configuration that are used by the
`DebugAdapterDescriptorFactory` to tell VS Code how to launch the debug
adapter:
- `debugAdapterHostname` - the hostname for an existing lldb-dap server
- `debugAdapterPort` - the port for an existing lldb-dap server
I've also removed the check for the `executable` argument in
`LLDBDapDescriptorFactory.createDebugAdapterDescriptor()`. This argument
is only set by VS Code when the debug adapter executable properties are
set in the `package.json`. The LLDB DAP extension does not currently do
this (and I don't think it ever will). So, this makes the debug adapter
descriptor factory a little easier to read.
The check for whether or not `lldb-dap` exists has been moved into the
new `DebugConfigurationProvider` as well. This way the extension won't
get in the user's way unless they actually try to start a debugging
session. The error will show up as a modal which will also make it more
obvious when something goes wrong, rather than popping up as a warning
at the bottom right of the screen.
This commit adds support for starting debug sessions through special
`vscode://llvm-vs-code-extensions.lldb-dap/start?config={launch-config}`
URIs. This allows tighter integration with custom scripts. One potential
use case is providing similar functionality to `xcdebug`, see #125777
for some discussion on that use case.
The functionality was inspired by @vadimcn's CodeLLDB extension, which
[provides similar
functionality](https://github.com/vadimcn/codelldb/blob/master/MANUAL.md#debugging-externally-launched-code).
This should ensure the extension only uses server mode if the binary
supports the feature, otherwise it will fallback to the existing
behavior.
Fixes#130854
This adds support for launching lldb-dap in server mode. The extension
will start lldb-dap in server mode on-demand and retain the server until
the VSCode window is closed (when the extension context is disposed).
While running in server mode, launch performance for binaries is greatly
improved by improving caching between debug sessions.
For example, on my local M1 Max laptop it takes ~5s to attach for the
first attach to an iOS Simulator process and ~0.5s to attach each time
after the first.
The Swift extension for VS Code requires that the `lldb-dap` executable
come from the Swift toolchain which may or may not be configured in
`PATH`. At the moment, this can be configured via LLDB DAP's extension
settings, but experience has shown that modifying other extensions'
settings on behalf of the user (especially those subject to change
whenever a new toolchain is selected) causes issues. Instead, it would
be easier to have this configurable in the launch configuration and let
the Swift extension (or any other extension that wanted to, really)
configure the path to `lldb-dap` that way. This allows the Swift
extension to have its own launch configuration type that delegates to
the LLDB DAP extension in order to provide a more seamless debugging
experience for Swift executables.
This PR adds a new property to the launch configuration object called
`debugAdapterExecutable` which allows overriding the `lldb-dap`
executable path for a specific debug session.
Support finding the lldb-dap binary with `xcrun` on Darwin or in PATH on
all other platforms.
Unfortunately, this PR is larger than I would like because it removes
the `lldbDapOptions`. I believe these options are not necessary, and as
previously implemented, they caused a spurious warning with this change.
The problem was that the options were created before the custom factory.
By moving the creation logic into the factory, we make sure it's only
called after the factory has been registered. The upside is that this
simplifies the code and removes a level of indirection.
Frequently, environment variables such as `LLDB_USE_NATIVE_PDB_READER`
are needed to be able to use lldb-dap in vscode
This PR adds a way to set the environment for the lldb-dap process using
configuration.
lldb-dap already supports a log file which can be enabled by setting the
`LLDBDAP_LOG` environment variable. With this commit, the log location
can be set directly through the VS-Code extension settings.
Also, this commit bumps the version number, such that the new VS Code
extension gets published to the Marketplace.
The main motivations behind this are two:
- Allow different companies developing their own vscode extensions for
LLDB to have a single contribution point, thus sharing resources and
working as a virtual large team.
- Allow for visual ways to configure the debugger, which currently has
to be done through launch.json files.
In terms of implementation, this is very straightforward and these are
the most important details:
- All the cpp code has been moved to a subfolder for cleanness. There's
a specific commit in the list of commits of this PR that just does that,
in case that helps reviewing this.
- A new folder `src-ts` has been created for the typescript code
- The ts extension can be used in two ways: as a regular vscode
extension and as a library. There file `extension.ts` explains which
entry point to use.
- The README has been updated the mention how to install the extension,
which is simpler than before. There are two additional sections for
rebuilding and formatting.
- The ts code I added merely sets up the debug adapter using two
possible options: reading the lldb-dap path from vscode settings or from
a config object passed by users of the extension is used as a library. I
did this to show how we can support easily both worlds.
