Rust instrumentation

This page covers how to enable coverage instrumentation for a Rust binary you plan to run in Antithesis. You’ll add a crate, reference it once in your code, and pass a handful of build flags. Find the crate here.

If you enabled rust instrumentation before May 22, 2026, you’re probably using the legacy method. We recommend switching to this method when you can, for now the other method is still supported.

Step 1: Add the dependency to .cargo/config.toml

[dependencies]
antithesis-instrumentation = "0.1"

Step 2: Include a reference to the library in your code

Somewhere in your Rust code, add this line at least once:

use antithesis_instrumentation as _;

Without it, Cargo treats the crate as unused and the linker drops the runtime shim. You can include this line in any Rust file in your project, it doesn’t matter which. You may also want to put this under a #[cfg].

Step 3: Adjust your build flags

There are two ways to do this: either at the command line or via a .toml file. You can pick either; you don’t need to do both.

Option A: Build flags at the command line

You’ll need to specify the —config options below. Your full command line will look something like this:

cargo build --bin main \
--config 'build.target = "x86_64-unknown-linux-gnu"' \
--config 'target.x86_64-unknown-linux-gnu.rustflags = [
"-Ccodegen-units=1",
"-Cpasses=sancov-module",
"-Cllvm-args=-sanitizer-coverage-level=3",
"-Cllvm-args=-sanitizer-coverage-trace-pc-guard",
"-Clink-args=-Wl,--build-id",
]'

Option B: Build flags in a .toml file

You can put the flags into .cargo/config.toml file instead like this:

[build]
target = "x86_64-unknown-linux-gnu"
[target.x86_64-unknown-linux-gnu]
rustflags = [
"-Ccodegen-units=1",
"-Cpasses=sancov-module",
"-Cllvm-args=-sanitizer-coverage-level=3",
"-Cllvm-args=-sanitizer-coverage-trace-pc-guard",
"-Clink-args=-Wl,--build-id",
]

Validation

To confirm that the instrumentation process was successful, you can run the command nm to list all the symbols in a binary, and then grep the string “antithesis_load_libvoidstar”.

nm client_binary | grep "antithesis_load_libvoidstar"
T antithesis_load_libvoidstar

Notice the “T” character in the previous code block: it means the symbol is in the text (code) section.

Symbolization

The LLVM compiler infrastructure will output debug symbols in the DWARF format. They could be separate debug info or just the original unstripped binary. These files should be symlinked (or moved) into a directory named /symbols in the root of the appropriate container image.

Help

If you need help with this, write to us at support@antithesis.com or talk to your forward deployed engineer.

  • Introduction
  • Welcome to Antithesis
  • How Antithesis works
  • Using Antithesis with AI
  • Get started
  • Setup guide
  • Overview
  • For Docker Compose users
  • For Kubernetes users
  • Test an example system
  • Overview
  • With Docker Compose
  • Overview
  • Build and run an etcd cluster
  • Add a test template
  • With Kubernetes
  • Overview
  • Build and run an etcd cluster
  • Add a test template
  • Product
  • Test templates
  • Overview
  • Creating test templates
  • Test commands
  • How to check a test template locally
  • How to port tests to Antithesis
  • Test launchers
  • The triage report
  • Overview
  • Findings
  • Environment
  • Utilization
  • Properties
  • Logs Explorer & multiverse map
  • Debugging
  • Overview
  • Causality analysis
  • Multiverse debugging
  • Simple Multiverse debugging
  • Advanced
  • Overview
  • The Antithesis multiverse
  • Querying with event sets
  • Environment utilities
  • Using the Antithesis Notebook
  • Cookbook
  • Tooling integrations
  • CI integration
  • Discord and Slack integrations
  • Issue tracker integration - BETA
  • Configuration
  • Access and authentication
  • The Antithesis environment
  • Best practices
  • Docker best practices
  • Kubernetes best practices
  • Optimizing for testing
  • Concepts
  • Properties and Assertions
  • Overview
  • Properties in Antithesis
  • Assertions in Antithesis
  • Sometimes Assertions
  • Properties to test for
  • Fault injection
  • Reference
  • Webhooks
  • Overview
  • Launching a test
  • Launching a debugging session
  • webhook reference
  • Antithesis API
  • Handling external dependencies
  • SDK reference
  • Overview
  • Define test properties
  • Generate randomness
  • Manage test lifecycle
  • Assertion catalog
  • Coverage instrumentation
  • Go
  • Go SDK
  • Instrumentor
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Java
  • Java SDK
  • Using the SDK
  • Building your software
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • C SDK
  • C++
  • C++ SDK
  • C/C++ Instrumentation
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • JavaScript
  • Python
  • Python SDK
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Rust
  • Rust SDK
  • Instrumentation
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • .NET
  • .NET SDK
  • Instrumentation
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Languages not listed above
  • Fallback SDK
  • Assert (reference)
  • Lifecycle (reference)
  • Assertion Schema
  • FAQ
  • Product FAQs
  • About Antithesis POCs
  • Release notes
  • Release notes
  • General reliability resources
  • Reliability glossary
  • Techniques for better software testing
  • Autonomous testing
  • Deterministic simulation testing
  • Property-based testing
  • White paper — How much does an outage cost?
  • Catalog of reliability properties for key-value datastores
  • Catalog of reliability properties for blockchains
  • Test ACID compliance with a ring test