Variable Inspection in Debugger

[kateinoigakukun]

Motivation

We have been supporting source-level debugging of Swift code in Chrome DevTools, but it doesn't support inspecting local variables on the paused call frame while it's supported in C/C++ Wasm binaries.

Preliminary Investigation

The Chrome DevTools extension extends the DevTools to interpret DWARF debug information embedded in WebAssembly binary. Because parsing & interpretation DWARF are well-known to be quite hard, they are porting existing native debugger implementation (LLDB, which is a part of LLVM project written in C++). The porting of the native debugger is done by Emscripten toolchain.

The variable inspection feature is done not only by DWARF information but also by cooperating with in-process compilers to know how the binary is code-generated and where member fields are placed in. So this means the DevTools extension ported not only the native debugger but also ported a part of Clang compiler.

Implementation Plan

Based on the preliminary investigation, we concluded what we need to integrate to the extension are:

• TypeSystemSwift, which bridges debugger and in-process Swift compiler
• A part of Swift compiler

• Build a part of Swift compiler using Emscripten
  • swiftAST
  • swiftASTSectionImporter
  • swiftBasic
  • swiftClangImporter
  • swiftFrontend
  • swiftIDE
  • swiftParse
  • swiftRemoteAST
  • swiftRemoteInspection
  • swiftSIL
  • swiftSILOptimizer
  • swiftSerialization
• Build Swift-related LLDB components using Emscripten
  • lldbPluginSwiftLanguage
  • lldbPluginSwiftLanguageRuntime
  • lldbPluginTypeSystemSwift
  • lldbPluginExpressionParserSwift
• Install TypeSystemSwiftTypeRef to the SymbolBackend's DefaultPluginsContext
• Make variable formatting work
  • Read reflection information from Wasm data segments
• Make swift::reflection::ReflectionContext work with Wasm object format for debugging purpose

Upstreaming

swiftlang/swift

• [AST] Explicitly cast uint64_t to size_t for 32-bit platforms swiftlang/swift#79340
• [DependencyScan] Use llvm::DefaultThreadPool instead of llvm::StdThreadPool swiftlang/swift#79341
• [build] Stop assuming llvm is always the top-level in unified build swiftlang/swift#79342
• [build] Add initial support for Emscripten SDK swiftlang/swift#79343
• [build] Configure library naming conventions for WebAssembly platforms swiftlang/swift#79344
• [SIL] Explicitly use uint64_t for maxBitfieldID swiftlang/swift#79347
• [wasm] Use __visibility__("default") for all wasm platforms swiftlang/swift#79349
• swiftlang@557e393

---

• swiftlang/llvm-project
  • kateinoigakukun/llvm-project@bb35d86
  • kateinoigakukun/llvm-project@30a5314
  • kateinoigakukun/llvm-project@2cd3e1b
  • kateinoigakukun/llvm-project@43acb04
• google/lldb-eval
• ChromeDevTools/devtools-frontend

[kateinoigakukun]

I need to clean up many stuff but I made a prototype here:

• Chrome DevTools: ChromeDevTools/devtools-frontend@main...kateinoigakukun:devtools-frontend:swift-debugging
• LLVM: swiftlang/llvm-project@swift-DEVELOPMENT-SNAPSHOT-2025-01-10-a...kateinoigakukun:llvm-project:yt/swift-debug
• Swift: swiftlang/swift@main...kateinoigakukun:swift:yt/swift-debug
• lldb-eval: google/lldb-eval@master...kateinoigakukun:lldb-eval:yt/swift-debug

[kateinoigakukun]

I released an enhanced version of the DevTools extension. Check https://github.com/swiftwasm/swiftwasm-book/blob/main/src/getting-started/debugging.md#enhanced-dwarf-extension-for-swift