Step3 evaluates the runtime semantic consistency between the repaired binary and the original binary.
Mainline call chain:
scripts/run_pipeline_in_docker.py
-> evaluator/semantic/run_instrumentation.py
-> evaluator/semantic/analyze_traces.py
The current implementation retains three semantic evidence layers:
Based on comparisons of parsable stable test-case lines in stdout:
exactpartialfailunsupported
Based on comparable function-call evidence:
- evidence available
- function I/O match
Based on low-level token-sequence diagnostic evidence:
- evidence available
- similarity
Notes:
- instruction-level here means diagnostic low-level token-sequence similarity
- it is not full instruction-trace equivalence
Each task writes Step3 outputs to:
results_<llm>_v4_full/<arch>/<src>/<bin_name>/<decompiler>/semantic/
Key files:
program_original.jsonprogram_decompiled.jsonstdout_original.txtstdout_decompiled.txttrace_original.txttrace_decompiled.txtsemantic_context.jsonresult_metrics.jsonresult_analysis.md
This is the main structured Step3 output and typically contains:
execution_statusquality_status- program-level metrics
- function-level metrics
- instruction-level metrics
For arm32 and x86, Step3 may require native recompilation at runtime to avoid glibc incompatibilities between the original binary and the guest runtime. Related metadata is recorded in semantic_context.json.
- The repository retains full Step3 results trees
- Historical rerun directories and supervisor tooling have been removed
- Absolute local paths and historical rerun paths in result metadata have been cleaned to match the current repository structure