CoreTrace is a modular analysis ecosystem for teams building security-sensitive and resource-constrained C and C++ software. It combines compiler-level static analysis, runtime instrumentation, reproducible reports, and CI integration to expose stack, memory, control-flow, and concurrency risks before release.

The project is intentionally split into independent components. The CLI orchestrates the workflow, the compiler layer owns Clang/LLVM integration, and each analyzer remains focused on one class of evidence. This separation keeps the system extensible and allows every tool to be used on its own or as part of the complete pipeline.

CoreTrace Analyzer is the main product experience. It is assembled from the coretrace orchestrator, coretrace-compiler, and the specialized analyzers rather than being implemented as one monolithic executable.

It:

• consumes C/C++ sources, compilation databases, and externalized analysis models;
• produces LLVM IR or instrumented binaries through the compiler layer;
• runs stack/resource, concurrency, and runtime analyses;
• reasons across translation units when project-wide context is required;
• normalizes findings into human-readable, JSON, and SARIF artifacts for local review, IDEs, and CI.

 C/C++ sources · compile_commands.json · analysis models
                         │
                         ▼
              ┌─────────────────────┐
              │    coretrace CLI    │
              │ config · orchestration
              │ reporting · policy │
              └──────────┬──────────┘
                         │
                         ▼
              ┌─────────────────────┐
              │ coretrace-compiler  │
              │ Clang frontend      │
              │ LLVM IR · instrumentation
              └───────┬────────┬────┘
                      │        │
           LLVM IR    │        │ instrumented program/events
          ┌───────────┴───┐    └──────────────────────┐
          ▼               ▼                           ▼
 ┌────────────────┐ ┌────────────────┐     ┌────────────────┐
 │ stack/resource │ │  concurrency   │     │    runtime     │
 │    analyzer    │ │    analyzer    │     │    analyzer    │
 └────────┬───────┘ └────────┬───────┘     └────────┬───────┘
          └──────────────────┴───────────────────────┘
                              │
                              ▼
               Human output · JSON · SARIF · traces
                              │
                              ▼
                     CI · IDE · GUI · audits

 Cross-cutting: coretrace-log · coretrace-testkit · CI adapters · tool template

This layered design avoids coupling analyzer logic to delivery concerns. Compiler-version integration is isolated in coretrace-compiler, analyzers exchange explicit artifacts instead of reaching into one another, and reporting remains at the orchestration boundary. New analyzers can therefore join the pipeline without duplicating frontend or CI logic.

• Separation of concerns — compilation, analysis, orchestration, and policy have distinct owners.
• Composable pipeline — tools work independently and together through explicit artifacts.
• CI-first evidence — JSON and SARIF are first-class outputs, not afterthoughts.
• Generic by default — configuration and external models replace project-specific hardcoding.
• Reproducibility — versions, build context, normalized outputs, and benchmark conditions are recorded.

CoreTrace uses LLVM because the project needs semantic program information, not only source-pattern matching.

• Precise representation: LLVM IR is typed, low-level, and SSA-based. It exposes instructions, values, control flow, calls, and memory operations required for stack, resource, data-flow, and cross-function reasoning.
• Faithful build context: Clang LibTooling and compilation databases let tools reuse the real include paths, macros, language mode, and compiler options of the analyzed target.
• Reusable artifacts: IR can be handled in memory, serialized as bitcode, or inspected as text. This supports caching, debugging, deterministic comparisons, and integration between tools.
• Modular analyses: LLVM's pass and analysis infrastructure fits CoreTrace's component model: an analyzer can compute or consume explicit results without owning the complete compiler pipeline.
• Appropriate scope: the approach is well suited to compiled C and C++ systems where buffer access, stack use, recursion, uninitialized values, and interprocedural behavior must be inspected below the syntax level.

The trade-off is higher implementation complexity, LLVM-version coupling, and occasional loss of source-level intent. CoreTrace contains that cost in the compiler/adaptation layer and preserves source locations through compiler metadata wherever possible.

The following controlled measurements cover the cross-translation-unit pipeline in coretrace-stack-analyzer. Lower elapsed time is better.

Each case was measured 25 times after 3 warmups, using a deterministic interleaved order. Parallel-corpus throughput increased from 171.5 to 252.0 files/s; cross-TU corpus throughput increased from 1,204.7 to 1,729.3 files/s.

The broader comparison between v0.6.0 and the current implementation shows a 43.55% lower median time, from 452.1 to 253.9 ms. This historical comparison is deliberately labelled non-causal because many changes separate the two versions.

• Parallelization: the same commit and executable were used; only jobs=1 versus jobs=4 changed.
• SCC worklist: adjacent commits 128e20c9 and 6a8c64f6 used exactly the same dependency versions, isolating the algorithm change.
• Functional equivalence: normalized JSON outputs were identical within every causal pair.

The SCC mechanism is also visible in internal timings:

• Parallel execution costs approximately +432 KiB between jobs=1 and jobs=4.
• The historical v0.6.0 → current comparison shows approximately +130 MiB RSS. It is not attributed to multithreading alone: the current version contains more analyses, caches, and cross-TU structures. This is documented as a trade-off.
• Existing CTest suite: 1/1 passed.
• Resilience scenarios: 3/3 passed on v0.6.0 and 5/5 passed on the current version, including a missing file, invalid IR, unsupported format, jobs=0, and SIGINT interruption.
• All 125 measured processes completed successfully.
• No existing test file was modified.
• Environment: LLVM/Clang 20.1.2, Release build, with machine and tool versions recorded.

CoreTrace repositories use independent versioning: a tag identifies the state of one repository and does not imply that every component has the same release number. Consumers should pin the exact repository tag or commit SHA used by their build.

Version tags found through the GitHub API on 2026-07-16:

Repositories absent from this table had no SemVer-shaped tag at the snapshot date. Components in a 0.x line may still introduce incompatible changes; check the repository release notes and compatibility constraints before upgrading.

# Run the orchestrated static and dynamic workflow
./ctrace --input main.cpp --entry-points=main --verbose --static --dyn

# Emit LLVM IR through the compiler wrapper
./cc -S -emit-llvm test.cc

# Run stack analysis in CI and export JSON + SARIF
python3 scripts/ci/run_code_analysis.py \
  --analyzer ./build/stack_usage_analyzer \
  --compdb ./build/compile_commands.json \
  --fail-on error \
  --json-out artifacts/stack-usage.json \
  --sarif-out artifacts/stack-usage.sarif

See each repository for build prerequisites and complete command-line options.

• CoreTrace wiki — CLI usage and project documentation
• Compiler wiki — compiler and instrumentation workflows
• Stack analyzer wiki — analyzer configuration and integration

Licensing is repository-specific. The core platform and active C++ analyzers are primarily Apache-2.0; coretrace-log uses MIT; coretrace-vscode, coretrace-testkit, and coretrace-apex use GPL-3.0. A repository marked Not declared or Not identified must not be assumed reusable without further clarification. Always inspect the target repository's license before redistribution or integration.

Contributions are welcome through the issues and pull requests of the relevant repository. For cross-component changes, describe the affected artifact contracts and compatibility expectations explicitly.