Abstract Local Execution

Concept

Abstract Local Execution is a filtering technique used in RISC-V negative-test compliance fuzzing that symbolically traverses the control flow of a generated bytestream to determine whether the test case is safe to keep. It tracks a program counter, per-register clean/dirty marks for address safety, and loop-visitation state to accept or drop candidate programs before they reach the ISS under test.

First seen 8/7/2026

Last seen 8/7/2026

Evidence 2 chunks

Wiki v1

WIKI

Abstract Local Execution

Overview

In the context of RISC-V compliance testing, Abstract Local Execution is the symbolic filtering step described in the paper Closing the RISC-V Compliance Gap: Looking from the Negative Testing Side (DAC 2020). It is performed by the fuzzer's filter on each candidate bytestream before the bytestream is accepted into the test suite and executed on a real (or simulated) RISC-V implementation.

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections

Closing the RISC-V compliance gap: Looking from the negative testing side ← uses 95% 1e

The paper uses abstract local execution in the filter to traverse local control flow.

LINKED ENTITIES

1 links

Closing the RISC-V compliance gap: Looking from the negative testing side USES Extracted graph relationship

CITATIONS

10 sources

10 citations — click to expand

[1] Abstract Local Execution is performed by the filter by traversing the local control flow of the bytestream and checking reachable instructions. Closing the RISC-V Compliance Gap

[2] The abstract execution state consists of a program counter (PC), a clean/dirty mark per register indicating address-safety, and data structures to track control flow to avoid loops. Closing the RISC-V Compliance Gap

[3] Initially PC is zero and all registers are dirty except x30 and x31, which are initialized with a label to data memory by the test case. Closing the RISC-V Compliance Gap

[4] The filter checks whether the next instruction is compressed via the two LSBs, decodes it, advances PC by 4 (normal) or 2 (compressed), and abstractly executes it; to avoid loops it ensures the same PC is not revisited. Closing the RISC-V Compliance Gap

[5] In the example program, a forbidden WFI instruction is never reached on any path, so the bytestream is still accepted by the filter. Closing the RISC-V Compliance Gap

[6] Branch and jump instructions (e.g., BLT, BEQ) fork the active abstract path so the traversal continues at multiple successor PCs simultaneously. Closing the RISC-V Compliance Gap

[7] The custom mutator only injects instructions that pass the filter, avoiding forbidden-category instructions and restricting load/store instructions to use x30 or x31 as the address register. Closing the RISC-V Compliance Gap

[8] The filter currently supports the RV32GC ISA, and the resulting test-suite can be executed on any sub-ISA of RV32GC (e.g., RV32I, RV32IMC); adding a new extension requires extending the filter, otherwise instructions from the new extension are treated as illegal and pass unconditionally. Closing the RISC-V Compliance Gap

[9] Floating-point registers are loaded and stored alongside general-purpose registers, guarded by the riscv_fdiv GCC define set for FP-capable -march selections. Closing the RISC-V Compliance Gap

[10] Bytestreams accepted by the filter are executed on the bit-true ISS of the open-source RISC-V VP, with additional custom coverage metrics (beyond ISS code coverage) used to guide fuzzing. Closing the RISC-V Compliance Gap