Skip to main content

extempore-debugging

Debugging and development guide for Extempore. Use when debugging JIT compilation issues, understanding symbol tracking, or testing compilation in different modes (batch, eval, interactive).

Quellinformationen

Repository
digego/extempore
Letzte Quellaktivität
7. September 2026 um 12:23
Erkannte Sprache von SKILL.md
Englisch
Sterne
1.464
Forks
128

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
extempore-debugging
description
Debugging and development guide for Extempore. Use when debugging JIT compilation issues, understanding symbol tracking, or testing compilation in different modes (batch, eval, interactive).
# Extempore debugging skill ## Architecture overview Extempore has three main layers: 1. **C++ runtime** (`src/`): Scheme interpreter, LLVM JIT, audio/OSC 2. **Scheme runtime** (`runtime/`): scheme.xtm, llvmir.xtm, llvmti.xtm 3. **xtlang libraries** (`libs/`): user-facing compiled DSL code ## Compilation paths ### Normal (interactive) compilation ``` llvm:compile-ir -> llvm:jit-compile-ir-string (Scheme FFI) -> jitCompile() in src/SchemeFFI.cpp -> initializeTemplateModule() parses runtime/bitcode.ll once -> parseAssemblyInto() of (type defs + user IR) -> EXTLLVM::addTrackedModule() (ORC JIT) -> EXTLLVM::addModule() (metadata tracking) ``` ### AOT compilation When `*impc:aot:current-output-port*` is set: ``` llvm:compile-ir -> impc:compiler:queue-ir-for-compilation -> appends to *impc:compiler:queued-llvm-ir-string* impc:compiler:flush-jit-compilation-queue -> llvm:jit-compile-ir-string with accumulated IR ``` ## Startup sequence 1. C++ `main()` in Extempore.cpp 2. SchemeProcess ctor loads `runtime/init.xtm` 3. SchemeProcess task loads `runtime/scheme.xtm`, `runtime/llvmti.xtm`, `runtime/llvmir.xtm` 4. Primary process compiles `runtime/init.ll` via `sys:compile-init-ll` 5. If `EXT_LOADBASE` is true (default), loads `libs/base/base.xtm` 6. `base.xtm` triggers AOT cache loading via `impc:aot:insert-header`/`impc:aot:import-ll` 7. AOT cache files (e.g. `libs/aot-cache/base.xtm`) call `llvm:compile-ir` with `.ll` files ## Key flags - `--nobase`: Skip loading base library (useful for debugging JIT in isolation) - `--noaudio`: Disable audio (required for headless/CI testing) - `--batch "expr"`: Batch mode (no server, single process); exits only if the expression calls `(quit ...)`. Implies `--noaudio` **unless `--audio-outfile` is also given** — in that case the offline file driver handles audio output. - `--eval "expr"`: Evaluate expression at startup but keep full server running (utility + primary processes, TCP server on port 7099). - `--audio-outfile <path>`: render DSP output to a float32 WAV file via an offline driver (see below). Combines with `--batch` for headless CI runs. - `--duration <seconds>`: cap on `--audio-outfile` render length. When reached, the driver finalizes the WAV and self-exits with status 0. 0/unset = render until `(quit)`. ### --batch vs --eval differences `--batch` creates a single SchemeProcess with no TCP server. `--eval` starts the full two-process setup (utility + primary) with TCP server, then evaluates the expression as a `LOCAL_PROCESS_STRING` task. **Bugs may reproduce in one mode but not the other.** The xtlang compiler's type inference state can differ because `--eval` has a utility process that also loads the base library into shared C++ statics (`sTypeDefinitions`, `sGlobalMap`). Always try both modes when investigating user-reported bugs, since users typically work interactively (equivalent to `--eval` / TCP eval). ## Symbol tracking `EXTLLVM::addModule()` populates `sGlobalMap` with function/global pointers: - Key: symbol name (string) - Value: pointer to `llvm::GlobalValue` in the metadata module clone `EXTLLVM::getFunction()` / `EXTLLVM::getGlobalValue()` look up symbols in this map. ## sTypeDefinitions accumulator `jitCompile()` maintains a static string `sTypeDefinitions` (~400KB after full library loading). It accumulates LLVM IR declarations (struct types, function declarations, external globals) from every successful compilation so that subsequent modules can reference earlier symbols. It is prepended to every user IR string before parsing: ``` fullIR = sTypeDefinitions + userIR ``` This is parsed via `parseAssemblyInto()` into a cloned template module (from `bitcode.ll`). If `sTypeDefinitions` contains a declaration that conflicts with something already defined in the template module, the parse fails silently (stderr is /dev/null) and the Scheme layer sees `#f` from `llvm:jit-compile-ir-string`, producing "FLUSH FAILED". ## Adhoc polymorphism names The xtlang compiler generates specialised function names for ad-hoc polymorphism using the pattern: ``` <basename>_adhoc_<counter>_<base64-encoded-type-signature> ``` For example: `xtm_play_adhoc_492_W05vdGVEYXRhKi...`. The base64 portion (`cname-encode`/`cname-decode` in `runtime/llvmir.xtm`) encodes the full type signature. These names can be extremely long (hundreds of characters). ## Common issues ### Type definitions AOT-compiled `.ll` files reference types like `%mzone`, `%clsvar` defined in `runtime/bitcode.ll`. These must be available when parsing user IR. ### Windows CRLF Regex-based IR parsing fails on Windows due to CRLF line endings. Use line-by-line parsing with explicit CR stripping. ### Symbol not found after compilation Check that: 1. Module was added to ORC JIT successfully 2. `EXTLLVM::addModule()` was called with the metadata clone 3. Symbol name matches exactly (including mangling like `_adhoc_`, `_poly_`) ### --batch mode hangs after errors When a compilation error occurs in `--batch` mode, the process does not automatically exit --- it hangs waiting for further input. Use `timeout` when running batch tests. The `sys:load-then-quit` helper is designed to exit after a timeout, but compilation errors can prevent it from reaching the quit call. ### Bug doesn't reproduce in --batch mode `--batch` runs a single process with no TCP server or utility process. `--eval` and interactive TCP eval run two processes (utility + primary) that share C++ statics like `sTypeDefinitions` and `sGlobalMap`. This means compiler bugs can appear in one mode but not the other. When a user reports a bug from interactive use: 1. First try `--batch` --- if it reproduces, great, it's the simplest to debug 2. If not, try `--eval` with the same expression 3. If not, start extempore normally and send the expression via TCP with `printf '(expr)\r\n' | nc -w 10 localhost 7099` 4. If the bug is specifically about redefinition or accumulated state, send multiple expressions sequentially via TCP to simulate an interactive session ## Scheme ↔ xtlang interop gotchas ### Calling xtlang functions from Scheme A top-level `bind-func` makes the function name callable from the Scheme interaction environment. `(bind-func foo ...)` → `(foo arg1 arg2)` works. Return values flow back (i64 → Scheme integer, double → real, etc.). ### `--batch` evaluates a single expression `--batch "<expr>"` reads one Scheme form. Multiple top-level expressions won't all run — wrap them in `(begin ...)`: ```bash # WRONG: only the first form runs --batch '(sys:load "foo.xtm") (foo_test)' # RIGHT --batch '(begin (sys:load "foo.xtm") (foo_test))' ``` ### `(quit rc)` and stdio flushing `exit_extempore` in `src/ffi/utility.cpp` calls `std::_Exit(rc)`, which bypasses destructors **and discards stdio buffers**. It explicitly `fflush(stdout)` before `_Exit` so xtlang `printf` output isn't lost. If you add another pre-exit cleanup step there, keep it short — `_Exit` runs right after. ### xtlang `set!` returns the assigned value Unlike Scheme where `set!` is effectively void, xtlang `set!` returns the new value. This breaks the common pattern `(if cond (set! x v))` with no else branch — the type inferencer sees `then: (type of v)` vs. implicit `else: void` and errors. Fixes: add explicit `void` branches, or wrap in `begin`: ```scheme ;; WRONG: type error "float vs void" (if (> v peak) (set! peak v)) ;; RIGHT (if (> v peak) (begin (set! peak v) void) void) ``` ### Mis-reading shell exit codes behind `|` `cmd | tail` puts `tail` as the last pipeline member, so `$?` is tail's exit code, not `cmd`'s. To check the actual program's exit status, either avoid the pipe (`cmd > file 2>&1; echo $?`) or use `PIPESTATUS[0]` in bash/zsh. This bit me while verifying `(quit 1)` propagation. ## Debugging commands ```scheme ;; List all modules (llvm:list-modules) ;; Print all modules (llvm:print) ;; Check if function exists (llvm:get-function "function_name") ;; Print specific function (llvm:print-function "prefix") ``` ## Sending expressions via TCP Extempore's TCP protocol requires `\r\n` (CRLF) termination. Expressions are read until `\r\n` is found (`src/SchemeProcess.cpp:541`). Without CRLF, the expression is buffered but never evaluated. ```bash # Start extempore with a specific port ./build/extempore --noaudio --port 17099 > /tmp/xtm_output.log 2>&1 & sleep 8 # wait for base library to load # Send an expression (printf for CRLF, nc for TCP) printf '(println 42)\r\n' | nc -w 5 localhost 17099 > /dev/null # Check output tail /tmp/xtm_output.log ``` Compilation output goes to extempore's stdout, not back through the TCP socket. The socket only returns `"Welcome to extempore!"` on connect and (optionally) the result of `ipc:` calls. TCP eval dispatches expressions as `SchemeTask::Type::REPL` tasks, which is the closest to how editors (VS Code, Emacs) send code interactively. This can produce different results from `--batch` because the evaluation context and process topology differ. ## Monkey-patching Scheme compiler functions To debug the xtlang compiler (type inference, callback handling, etc.), you can redefine Scheme functions at runtime via TCP to inject logging. This avoids rebuilding and lets you inspect internal state. ```bash # Redefine a compiler function to add debug output # (use define, not set! --- set! gets mangled by some code paths) printf '(define impc:ti:callback-check (let ((old impc:ti:callback-check)) (lambda (ast vars kts request?) (println (quote DEBUG) (quote ast:) ast) (old ast vars kts request?))))\r\n' | nc -w 10 localhost 17099 > /dev/null # Now trigger the code path you want to debug printf '(bind-func my_test (lambda (x:i64) x))\r\n' | nc -w 10 localhost 17099 > /dev/null # Check the debug output tail /tmp/xtm_output.log ``` Key runtime functions to instrument: | Function | File | Purpose | | ------------------------------- | ----------------- | --------------------------------- | | `impc:ti:callback-check` | `llvmti.xtm:7583` | callback arity/type checking | | `impc:ti:first-transform` | `llvmti.xtm` | AST transformation (macro expand) | | `impc:ir:compiler:callback` | `llvmir.xtm:4029` | callback IR generation | | `impc:ti:get-closure-arg-types` | `llvmti.xtm` | closure type lookup | ## Testing in isolation ```bash # Skip base library to test JIT directly ./extempore --nobase --batch "(begin (llvm:jit-compile-ir-string \"define i64 @test() { ret i64 42 }\") (println (llvm:get-function \"test\")) (quit 0))" # Test AOT cache loading ./extempore --nobase --batch "(begin (llvm:compile-ir (sys:slurp-file \"libs/aot-cache/xtmbase.ll\")) (quit 0))" ``` ## C++ debug output **stderr is unconditionally redirected to /dev/null** at startup (`src/Extempore.cpp:174`: `freopen("/dev/null", "w", stderr)`). Neither `std::cerr`, `fprintf(stderr, ...)`, nor any amount of flushing will produce visible output. Options: - Write to a file: `FILE* f = fopen("/tmp/xtm_debug.log", "a"); fprintf(f, ...); fflush(f);` - Write to stdout: `printf(...); fflush(stdout);` (mixes with Scheme output) - Temporarily comment out the `freopen` line for a debug build ## Building and testing ```bash # configure (fetches LLVM ~30s, full configure ~30s) cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DEXTERNAL_SHLIBS_GRAPHICS=OFF # build (LLVM is the bulk of the build time) cmake --build build --target extempore -- -j$(nproc) # run core tests (no audio needed, ~150s total) cd build && ctest -L libs-core --output-on-failure # run audio example tests (need audio libs built, each test has 300s timeout) cd build && ctest -L examples-audio --output-on-failure # quick smoke test of a specific file timeout 120 ./build/extempore --noaudio --batch \ '(sys:load-then-quit "examples/core/fmsynth.xtm" 10)' ``` Test labels: `libs-core`, `libs-external`, `examples-audio`, `examples-core`, `examples-graphics`, `audio-offline`. Defined in `extras/cmake/tests.cmake`. The `audio-offline` label covers two-phase tests that render a DSP file to a WAV via `--audio-outfile` and then assert on it with `libs/core/audiotest.xtm`. Register via `extempore_add_audio_offline_test(name render_xtm duration freq label)`. ### Examples as tests Examples are registered as tests via the `extempore_add_example_as_test` macro in `extras/cmake/tests.cmake`. They run with `--batch` (which implies `--noaudio`) using `sys:load-then-quit`: ```cmake extempore_add_example_as_test(examples/core/audio_101.xtm 10 examples-audio) ```
Auf GitHub ansehen
Diese SKILL.md ist sehr gross, daher zeigt SkillsMP hier nur den ersten Abschnitt. Auf GitHub ansehen