Files
Asuro/doc/src/arch/x86/arch.x86.panic.md
T
t3hn3rd 2d190c221a feature: boot.mgr replace hardcoded init sequence with dependency-driven boot manager
Introduce boot.mgr - a self-registering, dependency-ordered boot
initialization framework with barrier-based phasing and glob pattern
matching. Units now declare their own init procedures and dependencies
via registerBoot()/registerBarrier() in their initialization sections,
boot.mgr.run() topologically sorts and executes them.

- Add src/boot/boot.mgr.pas with topoSort, glob matching, barrier
  two-pass algorithm, and boot tree printer
- Gut src/asuro.pas (kmain): now just stores multiboot info, calls
  System.init(), boot.mgr.run, and yield()
- Add initialization sections with registerBoot() to 53 existing units
- Add new units: core.pas, test.pas, driver.storage.boot.pas,
  app.wasm.pas, app.bsod.pas (factored out of asuro.pas)
- Define 9 barrier phases: immediate -> early -> middle -> storage ->
  bus -> device -> bus.late -> late -> final
- Fix xHCI ISR: exclude PRC/WRC from PORTSC change bit clearing to
  prevent race with port reset busy-wait
- Fix driver.bus.usb.core fire_completion_hooks: guard against uint32
  underflow when CompletionHookCount = 0
- Move auto_mount_volumes from device barrier to late barrier so it
  runs after PCI scan discovers storage controllers
- Add toolchain/compile_initcalls.sh for boot entry extraction
- Add Boot Registration sections to all 51 doc files; create 4 new
  doc files; rewrite boot.mgr.md; update mkdocs.yml nav
2026-03-13 15:37:43 +00:00

48 lines
2.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# arch.x86.panic
x86-specific kernel panic bridge between the interrupt frame and the architecture-agnostic panic engine.
## Overview
This unit acts as the glue layer between the x86 interrupt subsystem and the architecture-neutral `core.panic` module. When a fatal CPU exception occurs, the fault handler calls `x86_panic`, which reads the saved register state from the global interrupt frame variables (`IntReg`, `IntErr`, `IntSpec`), packs it into a `TRegisterSnapshot`, and delegates to `core.panic.panic` for display and halt. The `init` procedure registers the x86-specific halt function and initialises the BSOD screen.
## Dependencies
- `core.panic` (interface)
- `arch.x86.util` (implementation)
- `arch.x86.isr.types` (implementation)
## Boot Registration
Registered with `boot.mgr` as `arch.x86.panic`, depending on glob `driver.video*` (waits for all matching entries).
## Functions and Procedures
### init
```pascal
procedure init;
```
Registers `arch.x86.util.halt_and_catch_fire` as the halt callback with `core.panic`, then calls `core.panic.init` to set up the BSOD display. Must be called after LVGL is initialised and before any fault handlers that may trigger a panic.
### x86_panic
```pascal
procedure x86_panic(fault : pchar; info : pchar);
```
Builds a `TRegisterSnapshot` from the current interrupt frame globals and invokes `core.panic.panic`.
- `fault` — Short fault identifier string (e.g., `'arch.x86.fault.gpf'`).
- `info` — Human-readable description (e.g., `'General Protection Fault.'`).
The snapshot includes, in order: EBP, EAX, EBX, ECX, EDX, ESI, EDI, DS, ES, FS, GS (from `IntReg`), ERROR (from `IntErr`), and EIP, CS, EFLAGS (from `IntSpec`). Fields whose corresponding pointer is `nil` are omitted.
Must be called after `correctInterruptRegisters()` has been called by the ISR wrapper so that `IntReg`, `IntErr`, and `IntSpec` point to the correct offsets within the saved interrupt frame.
## Notes
- The `addEntry` helper is internal and not exported. It appends one name–value pair to the snapshot, respecting the `MAX_REGISTER_ENTRIES` limit defined in `core.panic`.
- Whether `IntErr` contains a meaningful error code depends on the exception type. Faults that do not push an error code should call `correctInterruptRegisters(false)` before `x86_panic`, which causes `IntErr` to point to a zero-filled sentinel value.