runtime,cl: panic-site pc snapshots — deferred callers and fault stacks see the panic frames

[cpunion]

Second follow-up planned in #2004 (parallel with #2024): panic-site pc snapshots. gc runs deferred functions on top of the panicked stack, so runtime.Caller, CallersFrames and debug.Stack called from a deferred function — before or after recover() — see the panic frames. LLGo's longjmp unwinding removes them physically; this PR captures them at panic time and splices them back into every caller-info view.

Mechanism

• Capture: Panic() fills a per-thread snapshot through the SavePanicCallerFrames hook (empty since the shadow stack was removed). Recover() marks the recovering frame's fp: the snapshot stays observable exactly while that frame is live on the physical chain — matching how long gc keeps the panic frames on the stack — and can never leak into unrelated later walks.
• Splice: walks insert the snapshot below the live deferred frames at the defer-owner junction (matched by function entry; the snapshot side wins there because the live copy's pc is the longjmp resume site). One panic-machinery frame is kept where gc has runtime.gopanic — fixed Caller depths count it (issue5856's Caller(2)). The no-snapshot fast path costs one TLS load.
• Hardware faults: a SA_SIGINFO handler captures from the interrupted ucontext's pc/fp — the handler's own chain dead-ends at the signal trampoline, which is why fault snapshots were previously impossible. SIGSEGV, SIGBUS and previously-fatal SIGFPE (x86 integer division now recovers with gc's "integer divide by zero") all convert to Go panics, and their tracebacks start at the fault site, through C frames, into the Go callers. C is compiled with -fno-omit-frame-pointer so x86-64 chains hold.
• Attribution fixes found on the way: defer execution is attributed to the function's closing brace like gc (issue14646); explicit panic statements get their own statement anchor (issue5856); and a foreign (C) function linked between Go functions no longer steals the preceding Go function's name on darwin (dladdr cross-check in refinePCSymbolLine when no statement anchor covers the pc — cold, cache-backed path only).

Example — test/_manualtest/cexcept, NULL store in C called from Go, unrecovered:

panic: runtime error: invalid memory address or nil pointer dereference

goroutine 1 [running]:
cexc_mid_segv(...)
	???:0 +0x2d
cexc_segv(...)
	???:0 +0xc
main.callC(...)
	.../main.go:24 +0x34
main.viaGo(...)
	.../main.go:32 +0xc
main.main(...)
	.../main.go:53 +0x17c

goroot conformance

• xfails removed (all platforms): issue14646 (deferred Caller location), issue5856 (Caller(2) panic line through gopanic depth), issue33724 (debug.Stack after recover shows the panic-site method, not the inlined-away one).
• Still xfailed, reworded to the real blocker: bug347/348, issue29504/4562/27201 — the panicking statement's line in an untracked function needs statement-level granularity everywhere (P4b prebuilt pcline; statement anchors structurally require noinline under the ELF link-order mechanism, so they cannot be blanket-emitted today).

Known limitations (documented in the manual test)

• linux: C frames in fault stacks may display under a neighboring Go function's name — dladdr has no static symbols there, so the cross-check cannot fire (pre-existing for any C pc between Go functions; darwin is correct). The link-phase hole-sentinel follow-up (pclnpost sees the full symbol table) fixes naming and misattribution together.
• No sigaltstack yet: stack-overflow faults still kill the process.

Validation (both platforms + amd64 before push)

• macOS: acceptance suite (incl. the strengthened C-fault regression asserting the fault chain), statement-line and line-info suites, full test/go, goroot B-scope all green; plain/hot paths untouched (snapshot fast path is one TLS load).
• linux/arm64 container: acceptance + statement suites, cexcept fault chain frames, goroot trio green.
• linux/amd64 (qemu): SIGFPE recovers with gc's text; segv fault chain walks (frame pointers held by -fno-omit-frame-pointer).

Based on #2023 (contains #2012/#2016/#2019); independent of #2024.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 89.65366% with 236 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/build/funcinfo_table.go	88.19%	47 Missing and 29 partials ⚠️
internal/pclnpost/write.go	80.23%	21 Missing and 12 partials ⚠️
internal/build/funcinfo/funcinfo.go	87.60%	15 Missing and 14 partials ⚠️
internal/pclnpost/binary.go	86.79%	17 Missing and 11 partials ⚠️
internal/pclnpost/fixups.go	78.40%	18 Missing and 9 partials ⚠️
cl/instr.go	95.77%	14 Missing and 9 partials ⚠️
internal/build/build.go	78.57%	5 Missing and 4 partials ⚠️
internal/pclntab/pclntab.go	92.98%	2 Missing and 2 partials ⚠️
cl/compile.go	97.93%	2 Missing and 1 partial ⚠️
internal/pclnpost/pclnpost.go	91.30%	1 Missing and 1 partial ⚠️
... and 1 more

📢 Thoughts on this report? Let us know!