There are good reasons for building and integrating tools on our own where possible. Here is how I did it for LLDB and Visual Studio Code to profit from my own bugfix, before the next release got rolled out eventually.

TL;DR ↓ Build and integrate LLDB in vscode

Motivation

The LLVM project has a tight release cycle, publishing a new version every 6 months. Does this mean we will have our bugfixes rolled out in production quickly? Not quite. After the 6 months development cycle, the typical release and stabilization period takes up to 3 months and then it’s on the integrators to bundle new versions in their tools. For the example of the vscode-lldb plugin, a bug fixed in late January 2020 was available in production only in late October 2020:

2020, Jan 15:
11.0 release cycle starts with release/10.x branching from mainline
2020, Jul 15:
release/11.x branches from mainline
2020, Oct 12:
11.0 release officially available
2020, Oct 13:
vscode-lldb v1.6.0 bundles the new version

With only one day from release to production roll-out, Vadim Chugunov is an exemplary integrator certainly – and a lucky one with very few dependencies. Alpine Linux upgraded only on March 12, 2021 (because they were waiting for 11.1). That’s all is just the tip of the iceberg though. Toolchain roll-out is slow by definition and new releases are often not backported to existing distributions.

There is quite some official documentation on how to build LLDB, but it suffers from bitrotting at times like all documentation does. Do we really need to install subversion for building Release 12? And which optional dependencies do we need for the Visual Studio Code integration?

Build tip-of-tree LLDB

vscode-lldb uses LLDB’s Python interface. Enabling it in LLDB requires swig. As usual, we build with CMake and ninja:

> sudo apt-get install build-essential swig python3-dev git cmake ninja-build

> brew install swig git cmake ninja

Yes, the build will take a while:

> cd /workspace
> git clone --depth=1 https://github.com/llvm/llvm-project
> mkdir llvm-build && cd llvm-build
> cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=host -DLLVM_ENABLE_PROJECTS="clang;lldb" -DLLDB_ENABLE_PYTHON=On ../llvm-project/llvm
...
-- clang project is enabled
-- lldb project is enabled
-- Enable Python scripting support in LLDB: TRUE
...
> ninja lldb

Integrate tip-of-tree LLDB in Visual Studio Code

First of all, we need the vscode-lldb plugin. Then, we open a new workspace or folder and select Use Alternate Backend... from the Command Palette. We pass in the path to the just-built lldb executable (/workspace/llvm-build/bin/lldb in this example) and it will figure out the path to the liblldb dynamic library automatically. There should be a confirmation dialog popping up. And we get a new file entry in the workspace configuration:

{
  "lldb.library": "/workspace/llvm-build/lib/liblldb.13.0.0git.dylib"
}

Voilà!

Form now on the workspace will use the just-built LLDB for debugging. We can double-check with this custom launch configuration:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "lldb",
      "request": "custom",
      "name": "Dump Version",
      "initCommands": [ "version", "quit" ],
    },
  ]
}

Running it should dump something like this in the debug console:

Executing script: initCommands
lldb version 13.0.0 (https://github.com/llvm/llvm-project.git revision 792ee5be36926bca22291cc93595cf65d0cd6985)
  clang revision 792ee5be36926bca22291cc93595cf65d0cd6985
  llvm revision 792ee5be36926bca22291cc93595cf65d0cd6985