Skip to content

Analyzer Modules Architecture

Hugo edited this page Feb 26, 2026 · 1 revision

Analyzer Modules Architecture

This page describes the module split around StackUsageAnalyzer that keeps orchestration concerns separate from pass logic and reporting.


Goals

  • Reduce coupling between CLI/app orchestration and LLVM analysis details.
  • Keep module responsibilities narrow and independently testable.
  • Preserve existing behavior while improving maintainability.

Core Modules

src/analyzer/AnalysisPipeline.cpp

Role:

  • Coordinator for module-level analysis execution.
  • Orders preparation, pass execution, and diagnostic emission.

Pattern:

  • Facade over lower-level analyzer services.

src/analyzer/ModulePreparationService.cpp

Role:

  • Builds prepared module context (PreparedModule).
  • Computes stack metadata, filtered call graph, and recursion state.

Pattern:

  • Application service with deterministic derivation logic.

src/analyzer/LocationResolver.cpp

Role:

  • Resolves source file/line/column from LLVM debug metadata.
  • Provides fallback logic for alloca/debug intrinsics.

Pattern:

  • Stateless domain service.

src/analyzer/DiagnosticEmitter.cpp

Role:

  • Converts analysis findings to final Diagnostic objects.
  • Centralizes severity, rule IDs, message formatting, and CWE enrichment.

Pattern:

  • Adapter between analysis-domain findings and report-domain output.

src/analysis/Reachability.cpp

Role:

  • Classifies findings in statically unreachable code paths.

Pattern:

  • Isolated policy module.

Data Flow

  1. Input loading compiles/parses sources into an LLVM module.
  2. ModulePreparationService derives reusable analysis context.
  3. Analysis modules compute findings.
  4. Reachability annotates/filter findings where needed.
  5. LocationResolver maps findings to source coordinates.
  6. DiagnosticEmitter emits final diagnostics for human/JSON/SARIF outputs.

Why This Split

  • Better testability: each module has a narrow API and predictable inputs.
  • Clear evolution path: adding checks does not require touching CLI/app orchestration.
  • Lower regression risk: location/rule formatting logic is centralized.

Related Tests

Fine-grained unit tests:

  • test/unit/analyzer_module_unit_tests.cpp

Covered modules:

  • LocationResolver
  • Reachability
  • ModulePreparationService

Build target:

  • stack_usage_analyzer_unit_tests (enable with -DBUILD_ANALYZER_UNIT_TESTS=ON)

Clone this wiki locally