Claim: docs/tasks/5.1.md decodes an x86_64 nested-page fault into an architecture-neutral Access: the address, read/write/fetch, and whether the fault came from the guest's page walk. It leaves size and register unknown, because SVM doesn't report them and QEMU's TCG has no decode assist. A second guest program faults on purpose at 16 MiB to show it on a boot.

Passage: docs/WORKFLOW.md, Handing out a slice, step 1. The plan's 5.1 says the VMCB gives the same facts as ESR_EL2; it doesn't. That finding and the design choice it raises are on the forum for the maintainer (glint b142e85cea), and the task builds only what either answer needs.

Demonstration: QEMU 11.1.2 target/i386/tcg/system/excp_helper.c lines 524-544 put only the error code and SVM_NPTEXIT_GPA/GPT into EXITINFO1 and the address into EXITINFO2. svm.h lines 144-145.

Size: one new task.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KMXZyLk8eDgCjvQ9hX check-in: 34d29c2621 user: x86-1-glint tags: trunk

Claim: an unhandled trap in Glint's own code now ends its report with a backtrace. Each frame is a return address followed by its offset from the image base, so the host can name it. Glint::Backtrace follows the rbp chain within the stack the trap interrupted (the native stack, or the exception stack), with the guard page excluded. It checks each two-word record before loading it. It stops at a null, out-of-bounds, misaligned or non-ascending rbp, at a return address outside the image, or after 16 frames, so a corrupted frame ends the walk rather than faulting again. The existing report lines are unchanged and come first.

Passage: xv6 §4.5, paraphrased because the text isn't in the workspace: kerneltrap panics on an unexpected kernel trap.

Demonstration: on x86-1, fault printed four frames that llvm-nm on build/x86_64/glint.so names: #0 glint_x86_fault_instruction, #1 Glint::Shell.run, #2 glint_native_continue, #3 glint_switch_native_stack. spec/run/backtrace_spec.cr checks that naming for fault and fault 'write', and that overflow's walk ends within 16 frames. spec/backtrace_spec.cr walks fake stacks: a three-frame chain, a null terminator, a downward rbp, out-of-bounds and misaligned rbp, a return outside the image, and a 20-frame chain cut at 16. With panic-vectors and the phase 3 and 4 boots: 33 examples, 0 failures, 6 pending (aarch64). Codex reports the full suite with only aarch64 and glint-build all failures. Codex wrote it from docs/tasks/4.6.md; the reviewer made no changes. Review note: for #DF the CPU's saved RIP isn't meaningful, and frame #0 prints it anyway; the report above it already omits RIP for #DF.

Size: +91/-3 non-spec lines; walker 557 bytes; BOOTX64.EFI unchanged at 197,120 bytes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KMXZyLk8eDgCjvQ9hX Leaf check-in: 9f80e0888b user: x86-1-glint tags: slice/4.6-x86_64

Claim: docs/tasks/4.6.md adds a bounded frame-pointer backtrace to the report for an unhandled trap in Glint's own code. Each frame also prints as an offset from the image base, so the host can name it. The walk reads only checked addresses inside the interrupted stack, so a corrupted rbp ends it instead of faulting again. The boot spec names frames with llvm-nm and checks the fault routine and the shell appear.

Passage: docs/WORKFLOW.md, Handing out a slice, step 1.

Demonstration: Glint is built with --frame-pointers always (tools/glint_build.cr line 129).

Size: one new task.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KMXZyLk8eDgCjvQ9hX check-in: 9a56065018 user: x86-1-glint tags: trunk