Skip to content
STIMSMITH

Exception Handling

Concept

Exception handling is a cross-cutting concept that spans hardware-level CPU behavior, programming-language error-handling constructs, RISC-V assembly program generation, and RISC-V hardware extensions for control-transfer tracing. Evidence covers: (i) CPU emulator testing methodology and documented exception-handling defects; (ii) software-engineering studies of exception flows and anti-patterns in Java and C#; (iii) the CHIPS Alliance `riscv-dv` assembly generator's emission of exception-handler sections; and (iv) the RISC-V Control Transfer Records (CTR) extension, which provides hardware CSRs that explicitly classify control transfers by type, including `EXCEPTION` and `INTERRUPT` as first-class record categories.

First seen 5/27/2026
Last seen 7/29/2026
Evidence 8 chunks
Wiki v3

WIKI

Overview

Exception handling is a concept that spans multiple layers of computing, from hardware CPU behavior to high-level programming-language constructs. The provided evidence touches on exception handling in four distinct contexts: (i) CPU emulator testing, where exceptions are modeled as part of the abstract machine state and used to detect emulation defects; (ii) programming-language practices, where studies have examined exception flows and anti-patterns in Java and C# codebases; (iii) RISC-V assembly program generation, where the riscv-dv random instruction generator emits a dedicated exception-handling section; and (iv) RISC-V hardware extensions, where the Control Transfer Records (CTR) extension defines CSRs that classify recorded control transfers by type, treating exceptions and interrupts as distinct record categories alongside branches, calls, jumps, and returns.

Exception Handling in CPU Emulators

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

4 connections
Testing CPU Emulators ← mentions 100% 2e
The paper discusses exception handling as part of the testing methodology and defects found in emulators.
gen_section ← implements 1e
gen_section selects and implements exception handling instructions in the generated program.
CSR interactions part of → 82% 1e
Exception handling is closely related to CSR interactions in RISC-V verification.
RISC-V Control Transfer Records ← mentions 93% 1e
The CTR extension tracks exception events via CTRDATA_TYPE_EXCEPTION and provides EXCINH inhibit control.

LINKED ENTITIES

1 links
RISC-V Control Transfer Records MENTIONS Extracted graph relationship

CITATIONS

10 sources
10 citations — click to expand
[1] The Testing CPU Emulators study (ISSTA 2009) documents exception-handling defects in Pin, Valgrind, QEMU, and BOCHS, including missing exception notification in Pin, non-atomic instruction translation in Valgrind/QEMU, status-register deviations in BOCHS, and the physical CPU invariant that each instruction executes atomically with state preserved across exceptions. Testing CPU Emulators
[2] The EmuFuzzer methodology intercepts page-fault and runtime exceptions during test-case execution on both the physical CPU and emulator, and uses page-fault exceptions for lazy memory synchronization by protecting data pages and retrieving them on first access. Testing CPU Emulators
[3] A CPU abstract-machine state is modeled as a tuple s = (pc, R, M, E) where E is the exception state, with ⊥ indicating no exception and other values such as illegal instruction, division by zero, and general protection fault denoting specific exceptions. Testing CPU Emulators
[4] A 2017 study analyzed over 10,000 exception handling blocks and over 77,000 related exception flows from 16 open-source Java and C# (.NET) libraries and applications, finding that each try block has up to 12 possible potentially recoverable yet propagated exceptions, 22% of distinct possible exceptions trace back to multiple methods (average 1.39, maximum 34), and that there is a notable lack of documentation of possible exceptions. Revisiting Exception Handling Practices with Exception Flow Analysis
[5] A 2017 study collected exception anti-patterns from 16 open-source Java and C# libraries and applications using an automated exception-flow analysis tool, finding that only a few anti-patterns are commonly identified — Unhandled Exceptions, Catch Generic, Unreachable Handler, Over-catch, and Destructive Wrapping — with differences in prevalence between C# and Java. Studying the Prevalence of Exception Handling Anti-Patterns
[6] The RISC-V CTR extension adds CSRs CSR_MCTRCTL (0x34e), CSR_SCTRCTL (0x14e), CSR_SCTRSTATUS (0x14f), CSR_SCTRDEPTH (0x15f), and CSR_VSCTRCTL (0x24e), with a CSR_CTRCTL alias that maps to CSR_MCTRCTL or CSR_SCTRCTL depending on CONFIG_RISCV_M_MODE. [PATCH RFC 2/6] riscv: perf: Add Control transfer records CSR definations. — Linux Perf Users
[7] The CTR extension's xctrctl CSR exposes CTRCTL_EXCINH (0x200000000), CTRCTL_INTRINH (0x400000000), and CTRCTL_TRETINH (0x800000000) bits to selectively inhibit recording of exceptions, interrupts, and trap returns, alongside per-privilege enable bits and branch/call/return inhibit bits. [PATCH RFC 2/6] riscv: perf: Add Control transfer records CSR definations. — Linux Perf Users
[8] The CTR extension classifies recorded transfers using CTRDATA_TYPE values, with CTRDATA_TYPE_EXCEPTION = 1, CTRDATA_TYPE_INTERRUPT = 2, and CTRDATA_TYPE_TRAP_RET = 3 reserved as first-class record categories distinct from branches (4–5), reserved values (6–7), and call/jump/co-routine/return types (8–15). [PATCH RFC 2/6] riscv: perf: Add Control transfer records CSR definations. — Linux Perf Users
[9] The sctrdepth CSR selects record-buffer depth with SCTRDEPTH_MIN (0x0) corresponding to 16 entries and SCTRDEPTH_MAX (0x4) corresponding to 256 entries, and the sctrstatus CSR exposes SCTRSTATUS_WRPTR_MASK (0xFF) and SCTRSTATUS_FROZEN (0x80000000), with record storage located at CSR addresses CTR_ENTRIES_FIRST (0x200) through CTR_ENTRIES_LAST (0x2ff). [PATCH RFC 2/6] riscv: perf: Add Control transfer records CSR definations. — Linux Perf Users
[10] In RISC-V verification practice, exception paths are recognized as a critical area that must be exercised, and coverage models are recommended to identify which exception paths, privilege transitions, debug entries, and CSR interactions must be observed beyond what random instruction generation alone produces. RISC-V Verification: Five places projects lose weeks