StigAnalysisP5DeriveInterfacePointsTask

stigAnalysisP5DeriveInterfacePoints derives LLVM symbols for the element's interface points (sources, sinks, and entry points) from the final transformed P5 analyzer input.

The task has two configuration modes:

Mode 1: LLVM harness discovery (default — interfacePointMode = LLVM_HARNESS_DISCOVERY)

• Input: module.ll + optional ASIL annotation JSON

• Logic: Scan LLVM IR, demangle symbols with the pinned LLVM demangler, match the hard-coded harness templates harness::SourceGroup<, harness::SourceLeaf<, harness::SinkGroup<, and harness::SinkLeaf<, then resolve configured harness entry points from module.ll.

• Output: component_interface_points_llvm_symbols.json, discovery_symbols.json

This mode does not scan C++ harness source files. It only reads the compiled LLVM IR (module.ll) and derives interface points from demangled harness symbols. The annotation JSON can provide ASIL metadata for discovered points; it does not create source/sink symbols by itself.

Mode 2: DSL declaration (manual — interfacePointMode = DSL_DECLARATION)

• Input: module.ll + DSL-declared source/sink tokens (demangled C++ names)

• Logic: Scan module.ll → demangle ALL symbols → build reverse map (demangled→mangled) → look up each DSL token in the reverse map → resolve entry points from module.ll

• Output: component_interface_points_llvm_symbols.json (same format), discovery_symbols.json (same format)

This mode takes DSL-declared demangled names (e.g., ns::Class::ReadFoo()), scans module.ll for ALL mangled symbols, demangles them all, builds a reverse map, and looks up each token to find its mangled name. Entry points are still resolved from module.ll using the normal selector logic.

Key properties

• Both modes produce the same output format. Both write component_interface_points_llvm_symbols.json with name = mangled LLVM symbol and demangledName = human-readable. Downstream tasks (stigAnalysisP5GenerateAnalyzerRunPlan, stigAnalysisP6RunAnalyzer, stigGenerateMarkdown) don't care which mode produced the file.

• Both modes need module.ll (bitcode). Even in DSL_DECLARATION mode, compilation to bitcode is required because DSL tokens are demangled C++ names, while PhASAR needs mangled LLVM symbols. The only way to resolve this mapping is to scan the compiled module.

• Phase 2 vs Phase 3: In Phase 2 the task reads stigAnalysisP3BuildProvenanceBitcode/module.ll (all TUs). In P5 it reads stigAnalysisP5ApplyBitcodeTransforms/module.ll (final analyzer input). Each phase does its own independent symbol discovery/resolution.