On Apple platforms, the development experience was designed around making the compile-link-debug cycle as fast as possible. For debugging, that means that rather than processing large amounts of DWARF to link it into the final binary, the linker leaves the debug info in the object files and records a debug map that tells the debugger where to find it. When you’re debugging locally, that’s all you need. But if you want to archive the debug info for crash reporting or remote debugging, you need a way to produce a self-contained bundle. That’s where dsymutil comes in. ...

Enhanced Memory Tagging Extension (EMTE) is a hardware-based security technology to protect against memory corruption vulnerabilities. Memory allocations are tagged with a secret key. When memory is accessed, the hardware validates the tag, and if it doesn’t match, stops the process. EMTE is the foundation of Apple’s Memory Integrity Enforcement (MIE). It’s available on A19 and M5 processors or later. Using MTE for Finding Bugs (E)MTE is not just valuable in a security context. It was originally designed as a tool for hardware to help find memory corruption bugs. Compared to other tools for detecting memory safety issues, such as AddressSanitizer, MTE has several benefits. Most notably, its CPU and memory overhead are significantly smaller than software-assisted tools, usually somewhere in the single-digit percentage range. For comparison, ASan usually has a 2x slowdown and a 3x memory overhead. MTE also requires no recompilation and can be dynamically turned on and off at runtime. ...

LLDB comes with built-in syntax highlighting for C-based languages. It does so using the embedded clang compiler. Other languages following this model of embedding the compiler, such as Swift, can take a similar approach. Motivation There are two important use cases where relying on the compiler for syntax highlighting doesn’t work: Some languages, like Rust and Zig, don’t have their own type system and instead reuse the Clang type system. LLDB has the ability to create synthetic stack frames representing any language, including interpreter languages like Python. In both scenarios, there is no embedded compiler to rely on for syntax highlighting. Creating a language plugin for every language, each with its own syntax highlighting library dependency doesn’t scale. ...

This post summarizes the major areas of development in LLDB in 2025. I was inspired by Nikita Popov’s “This year in LLVM” and thought it would be interesting to do something similar for LLDB. My goal was to cover the whole project, rather than focusing on my own contributions.1 As the maintainer, I try to look at every single LLDB PR, but my level of engagement varies. I expect there will be a subconscious bias towards the efforts I was involved in. If there’s an area of work I didn’t include here, more likely than not it’s because I forgot, not because I didn’t think it was important. ...

I’ll be presenting WebAssembly Debugging with LLDB in the LLVM Dev Room at FOSDEM 26 on Saturday, January 31st. Abstract WebAssembly support in Swift started as a community project and became an official part of Swift 6.2. As Swift on WebAssembly matures, developers need robust debugging tools to match. This talk presents our work adding native debugging support for Swift targeting Wasm in LLDB. WebAssembly has some unique characteristics, such as its segmented memory address space, and we’ll explore how we made that work with LLDB’s architecture. Additionally, we’ll cover how extensions to the GDB remote protocol enable debugging across various Wasm runtimes, including the WebAssembly Micro Runtime (WAMR), JavaScriptCore (JSC), and WasmKit. ...

This post describes how to debug WebAssembly code running under the WebAssembly Micro Runtime (WAMR) on macOS. WAMR is a lightweight WebAssembly runtime designed for embedded and IoT applications, but its simplicity and debugging support make it well suited for general development. Building the WebAssembly Micro Runtime We have to build the runtime with debugging support. Start by cloning the wasm-micro-runtime repository and optionally check out a specific release. $ git clone [email protected]:bytecodealliance/wasm-micro-runtime.git $ cd wasm-micro-runtime $ git checkout release/2.4.x Next, build iwasm. This is the binary that uses WAMR VMcore and allows us to interact with it from the command line. We need to enable debugging support (WAMR_BUILD_DEBUG_INTERP=1) and specify the target architecture (WAMR_BUILD_TARGET=AARCH64 for Apple Silicon). I’m using Ninja as the generator since that’s what I’m used to when building LLVM and LLDB. ...

WebAssembly (Wasm) is a low-level binary instruction format. It was originally created to run in the browser, but has gained traction in many non-browser environments as well. Debugging WebAssembly applications presents unique challenges compared to traditional native code debugging. Unlike native executables that run directly on the processor, WebAssembly code executes within a virtual machine that abstracts away the underlying hardware. This abstraction, while providing portability and security benefits, complicates the debugging process because debuggers cannot rely on standard debugging techniques. ...

I was recently answering questions about dsymutil’s multi-threading model and lockstep algorithm. I decided to write it down here for future reference. This article focuses on types and the .debug_info section. Background As a reminder, dsymutil is an optimizing DWARF linker. It only retains debug info for elements that appear in the final executable. It uses the One Definition Rule (ODR) to unique C++ types. As will become clear, both of these heavily shaped its design. ...

Mach-O (Mach Object) is a binary file format used by macOS and iOS for executables, libraries, and object code. A Mach-O file consists of a header, followed by a series of load commands, and then a series of segments. The 4GB Limitations The original 32-bit format used 32-bit offsets, which can address a maximum of 2^32 bytes, or 4GB of memory. The 64-bit variant uses 64-bit offsets, vastly increasing the addressable memory space. However, somewhat surprisingly, the on-disk size of a Mach-O file is still limited to 4GB due to the use of 32-bit file offsets. ...