DtTsa

DtTsa is a synchronization-aware dynamic thread-sharing analysis for multithreaded C/C++ programs. It is implemented as an LLVM instrumentation pass together with a lightweight runtime library.

DtTsa instruments memory accesses together with key synchronization events, records dynamic execution traces during program runs, and reports source-level thread-sharing points that can be used for program understanding, concurrency debugging, and schedule-focused testing.

This repository contains:

• the LLVM pass implementation (src/MemAccessInstrumentPass.cpp)
• the runtime support library (src/runtime.c)
• the analysis outputs produced by DtTsa on three benchmark suites (evaluation/results/)

---

Repository Layout

DtTsa/
├── README.md
├── src/
│   ├── MemAccessInstrumentPass.cpp
│   └── runtime.c
└── evaluation/
    ├── README.md
    └── results/
        ├── CVE-Benchmarks/
        ├── DataRaceBench/
        ├── paper/
        └── SCTBench/

• src/ contains the core implementation of DtTsa.
• src/MemAccessInstrumentPass.cpp implements the LLVM instrumentation pass.
• src/runtime.c implements the runtime tracing support.
• evaluation/ contains benchmark and result documentation.
• evaluation/results/ contains summarized analysis outputs and selected experimental materials.

---

What DtTsa Does

Given a multithreaded C/C++ program, DtTsa:

1. compiles the program to LLVM bitcode;
2. inserts instrumentation before memory accesses and synchronization operations;
3. links the instrumented program with a runtime support library;
4. records dynamic trace events during execution;
5. aggregates the observed events across runs; and
6. reports source-level thread-sharing points together with their frequency across runs.

DtTsa is a dynamic analysis tool. It reports sharing behavior observed in executed paths and schedules. It is not intended to prove the absence of unobserved sharing.

---

Environment Requirements

DtTsa is intended to be built and used on Linux or WSL2.

Required Tools

• clang
• clang++
• llvm-config
• opt
• python3
• standard Unix utilities such as bash, make, sed, grep, and awk

Suggested Environment

• Ubuntu 20.04 / 22.04, or WSL2 with Ubuntu
• a consistent LLVM/Clang toolchain version for:
  • clang / clang++
  • opt
  • llvm-config

Version Check

clang --version
clang++ --version
opt --version
llvm-config --version
python3 --version

Important: the LLVM version used to build the pass should match the LLVM version used to instrument the target program.

---

Building DtTsa

Build the LLVM pass from the repository root:

clang++ `llvm-config --cxxflags` -fPIC -shared src/MemAccessInstrumentPass.cpp \
  -o libMemInst.so `llvm-config --ldflags --system-libs --libs core ipo passes`

Build the runtime library:

clang -fPIC -shared src/runtime.c -o libruntime.so -lpthread

After successful compilation, the repository root should contain:

libMemInst.so
libruntime.so

---

Input and Output

Input

DtTsa takes the following inputs:

1. a multithreaded C/C++ program;
2. LLVM bitcode generated from that program;
3. one or more program runs, such as tests, benchmark drivers, or PoCs.

This repository does not directly store the full benchmark source trees due to repository-size considerations. Instead, the benchmark suites should be obtained separately and placed under the expected local directories described in evaluation/README.md.

Output

DtTsa produces dynamic-analysis outputs derived from runtime traces. Depending on the target program and benchmark setup, the output may include:

• raw trace logs;
• intermediate per-run dynamic records;
• merged source-level sharing summaries;
• text, JSON, or other summarized results.

The benchmark-level outputs included in this repository are stored under:

• evaluation/results/CVE-Benchmarks/
• evaluation/results/DataRaceBench/
• evaluation/results/SCTBench/

At a minimum, DtTsa reports source-level thread-sharing points observed during execution. When repeated runs are used, DtTsa can also summarize the frequency or stability of each reported site across runs.

---

Using DtTsa on a Single Program

This section describes the generic workflow for applying DtTsa to a single program.

Step 1. Compile the Target Program to LLVM Bitcode

For a C program:

clang -g -emit-llvm -c target.c -o target.bc

For a C++ program:

clang++ -g -emit-llvm -c target.cpp -o target.bc

If the target uses threads or OpenMP, add the corresponding flags during compilation and linking, for example:

• -pthread
• -fopenmp

Step 2. Instrument the Bitcode with DtTsa

Use the DtTsa pass to transform the bitcode into an instrumented version.

The pass has been tested with the following invocation style:

opt -load-pass-plugin /path/to/libMemInst.so -passes=meminst target.bc -o target_inst.bc

Replace:

• /path/to/libMemInst.so with the actual path to the compiled pass library
• target.bc with the input LLVM bitcode file
• target_inst.bc with the instrumented output bitcode file

Step 3. Link the Instrumented Bitcode with the Runtime Library

For a C target:

clang target_inst.bc /path/to/libruntime.so -lpthread -o prog

For a C++ target:

clang++ target_inst.bc /path/to/libruntime.so -lpthread -o prog

Replace:

• /path/to/libruntime.so with the actual path to the runtime library
• prog with the desired executable name

If needed, also add -fopenmp.

Step 4. Run the Instrumented Executable

./prog

If the program requires command-line arguments:

./prog <program-arguments>

Step 5. Inspect the Output

After execution, DtTsa emits runtime-generated dynamic-analysis outputs. Depending on the target program and benchmark setup, the output may include:

• raw runtime traces;
• per-run dynamic records;
• source-level sharing summaries;
• merged results across repeated runs.

The included benchmark outputs are organized under:

evaluation/results/

---

Repeated Runs

Concurrency behavior may depend on scheduling and input diversity. DtTsa therefore supports repeated executions of the same subject.

For a subject program, repeated runs produce per-run sharing sets. These sets can be merged into a cumulative union set, and each reported sharing point can be summarized by its occurrence frequency across runs.

This is useful for distinguishing stable sharing points from rare schedule- or input-sensitive ones.

---

Benchmark and Evaluation Materials

The repository contains summarized outputs and selected materials for the following benchmark families:

evaluation/results/CVE-Benchmarks/
evaluation/results/DataRaceBench/
evaluation/results/SCTBench/
evaluation/results/paper/

The full external benchmark source trees, generated LLVM bitcode, instrumented binaries, complete raw traces, and large temporary logs are not duplicated in this repository.

See evaluation/README.md for details about the evaluation directory and result organization.

---

Output Interpretation

At a minimum, DtTsa reports source-level thread-sharing points observed during execution.

A reported sharing point usually contains information such as:

• source location;
• function name;
• access kind;
• thread-sharing evidence;
• synchronization context when available.

When repeated runs are used, DtTsa can also summarize how frequently each reported site appears across executions.

---

Notes

DtTsa reports execution-grounded sharing information. Its completeness depends on the exercised inputs, schedules, and supported synchronization operations.

The tool is intended to help developers inspect observed cross-thread sharing and to provide compact scheduling candidates for downstream concurrency testing.