runtime: link-phase ftab/findfunctab generation (Stage 2, P1–P3)#2016
Open
cpunion wants to merge 54 commits into
Open
runtime: link-phase ftab/findfunctab generation (Stage 2, P1–P3)#2016cpunion wants to merge 54 commits into
cpunion wants to merge 54 commits into
Conversation
Bring over the cross-branch runtime funcinfo benchmark (hot, deep, multipkg, cold, stdlib scenarios) so xgo-dev#2012 can reproduce its own performance numbers. cold.FirstCallersFrames now walks to the first fully symbolized frame, because synthetic runtime frames (LLGo's runtime.Callers placeholder) carry no file/line and the metric was silently skipped on LLGo. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
macOS previously had no entry/stub/pcline site sections, so first-use funcinfo initialization fell back to one dlsym per function and per stub (13ms cold on a small binary, 27ms with LTO), and statement-level pc-line records did not exist at all. Emit the same site records on Mach-O: - __DATA,__llgo_fie / __llgo_stub / __llgo_pcl sections with the live_support attribute: under ld64/lld -dead_strip a live_support atom survives only if the atom it references (the anchor label inside the function body) is live, which matches the records-follow-function semantics ELF gets from SHF_LINK_ORDER with --gc-sections. - One lowercase-l linker-private symbol per record so each record is its own atom and dead functions drop exactly their own records. - Assembler-local (L-prefixed) pc-site labels: Mach-O subsections-via-symbols treats visible labels as atom boundaries, and a visible label in the middle of a function let the linker split and reorder function bodies. - Boundary symbols via ld64's section$start$/section$end$, emitted with the \x01 verbatim-name prefix so LLVM does not prepend the Mach-O underscore. - A no_dead_strip zero record per section in the main module keeps the sections (and their boundary symbols) present even when no package contributed records. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
First-use initialization: - Skip the per-stub dlsym loop when the stub-site section provided the frames; each dlsym is a dynamic-loader query and the loop dominated cold latency. - Materialize per-function strings and entry PCs once per function and packed file strings once per file ID during pcline table construction instead of once per site. Cold FuncForPC fast path: before the frame table exists, resolve exact function-value PCs with a bounded linear scan of the raw entry-site and stub-site sections (compile-time data, no loader query), then one dladdr as fallback; both require an entry match within the warm path's slack so stripped-local misattribution is impossible. The path is budgeted: after a handful of cold lookups the sorted table amortizes better, so it is built as usual. cold.FirstFuncForPC drops from 13ms to ~35us on macOS. Find index: subbucket deltas are now uint16 and the whole-index abandonment on delta overflow is gone. Go stores uint8 deltas because its linker guarantees a 16-byte minimum function size; LLGo indexes call-site records that sit a few bytes apart, and a dense 4KiB bucket silently degraded every lookup in the process to a full binary search. A delta counts deduplicated PCs inside one bucket, so it is bounded by the bucket size and uint16 cannot overflow. Observability: LLGO_FUNCINFO_DEBUG=1 prints one line per lazily built table (frame/bucket counts, index built or fallback, sites vs dlsym sources) so benchmarks can tell which path they measured. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Every Caller/Callers capture used to intern the frame into the synthetic table: a hash probe plus a full frame comparison per stack slot per call. Memoize the interned PC base in the shadow-stack slot and invalidate it when the recorded line changes (for one entry the instrumented name/file operands are constants, so the line is the only thing that varies between call sites). The three static frames emitted around every Callers walk get per-store memo slots, and the emit loop is unrolled so nothing escapes and skipped frames are never captured. macOS: hot.CallersOnly 182ns -> 125ns (Go 1.26: 118ns); with LTO 96ns. hot.CallersFramesFirst 528ns -> 471ns, 354ns with LTO (Go: 401ns). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…py limit Frames.Next allocated a fresh *Func per symbolized frame; route it through the FuncForPC 4-way cache so repeated CallersFrames walks over the same PCs stop allocating. hot.CallersFramesFirst: macOS 471->456ns (338ns with LTO, Go 1.26: 406ns); Linux LTO reaches parity at 433ns. Also document a pre-existing limitation at the entry-site emitter: the body-embedded inline-asm record is duplicated by LTO inlining into every inline site (~4x section growth on multipkg) and registers host-function PCs under the inlinee's symbol ID. Runtime only consults the table when native symbolization fails, which bounds the impact; the fix (data globals with !associated metadata) needs LLVMGlobalSetMetadata in the llvm binding and lands with the link-phase ftab work. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Record the experiment results at the emitter: !associated only guides linker GC and IR-level GlobalDCE deletes the records; llvm.compiler.used pins dead functions through the records' address initializers; and noduplicate blocks inlining. Section dedup is link-phase work. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Post-link table generation plan: parse the linked binary's metadata sections, dedup LTO inline copies against the symbol table, sort with a sentinel, build Go-layout findfunctab via internal/pclntab, and write back into a reserved section with ASLR-safe anchor offsets. Runtime adopts the prebuilt table when the header validates and keeps first-use construction as fallback. Includes the list of platform facts established in xgo-dev#2012 so implementation does not re-derive them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Jul 2, 2026
codecov/patch was failing at 51.77% (target 88.68%), but the shortfall was almost entirely benchmark/runtime_funcinfo/main.go — a standalone measurement harness with no unit tests by design (600 of 639 missed lines). Compiler-side changes were already covered (cl/instr.go 478/493, cl/compile.go 125/127). Ignore benchmark/** in codecov and cover the remaining internal/pclntab validation/lookup edges directly (96.2%). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
cpunion
force-pushed
the
codex/pclntab-linkphase-p1
branch
from
f91edf9 to
89a1b4e
Compare
Only macOS ran tests with -coverprofile, so lines behind OS-specific branches (ELF emission, per-OS runtime shims) always showed as missed in codecov/patch even though the ubuntu job executed them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
cpunion
force-pushed
the
codex/pclntab-linkphase-p1
branch
2 times, most recently
from
201b7bb to
1a9ca68
Compare
Covers the ELF and Mach-O directive branches, 32-bit pointer directives, quote-escaped symbol names and empty-table emission from one table-driven test, so single-platform coverage runs stop reporting the other platform's branches as dead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
First stage of doc/design/pclntab-linkphase.md: parse a linked binary's funcinfo entry/stub sections (Mach-O and ELF), deduplicate LTO inline copies against the symbol table's text ranges, sort with a Go-style sentinel, and build findfunctab through internal/pclntab — the faithful port that has been waiting for exactly this caller. Read-only: prints what the P2 build integration would write back. Measured on the 576-target multipkg binaries: - non-LTO: 9319 records -> ftab 3161 + 207 buckets; lookup self-check 3160/3160; site sections 149KB -> 29KB (5.1x) - LTO: 15371 entry records -> 13857 inline copies dropped, 4144 kept; self-check 3045/3045; 299KB -> 28.5KB (10.5x) Findings for P2: on-disk Mach-O pointer slots hold dyld chained-fixup encodings (low 36 bits are the target; decoded here; the write-back design stores anchor-relative offsets and avoids pointers entirely), and some non-LTO stub symbols are absent from the symbol table (records conservatively dropped; needs tightening). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…adoption
pclnpost -write rewrites the entry-site section in place with the
prebuilt table (header + ftab {entryOff,funcIndex} + runtime-layout
findfunctab buckets), resolving funcinfo indexes through the binary's
symbol-index section, and voids the stub section (its records are
merged into the table). ASLR is handled by anchoring on the section's
own link-time address; entries are normalized to true symbol starts,
which retires the entry-PC slack on this path. macOS re-signs with an
ad-hoc codesign after rewriting.
The runtime adopts the table zero-copy when the magic header validates:
lookups binary-search the on-disk ftab directly through the shared
bucket index, nothing is materialized on first use (the funcIndex ->
entry map is built lazily and only for the pcline initializer), and the
cold scan/dladdr path is skipped since adoption is cheap. First-use
construction remains the fallback whenever the header is absent.
Linux end-to-end: entries=prebuilt, FuncForPC/FileLine correct,
first-FuncForPC 110µs (materializing) -> 6-8µs (zero-copy); 13ms on the
original macOS baseline. Known gap: on macOS the on-disk rewrite is
corrupted at load time because dyld still walks the stale chained-fixup
chain over the section; fix (unlinking the section's nodes from the
page chains in LC_DYLD_CHAINED_FIXUPS) is identified and next.
Non-prebuilt paths verified regression-free: cl + test/go suites pass,
smoke behavior unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Every llgo-linked executable (linux/darwin, sites enabled) now gets the prebuilt ftab/findfunctab automatically: internal/build runs internal/pclnpost.Rewrite after linkMainPkg, and any failure degrades silently to the first-use construction fallback. Moves the tool core into internal/pclnpost and hardens it: - Canonical-record detection by FNV: a record survives when its anchor's owning symbol hashes to the record's symbolID (or is the __llgo_stub. wrapper of it). The previous one-per-symbolID rule wrongly collapsed a function with its stub — they share the target's symbolID by design — which broke exact-entry lookups (caught by TestRuntimeLineInfoAndStack on Linux). LTO inline copies are now identified exactly: 8.4k/9.5k copies removed in the LTO probes. - Mach-O chained-fixups surgery: unlink the rewritten sections' pointer slots from the dyld page chains (repointing predecessors' next links and page_start entries) so dyld neither rebases slots inside the new table nor skips unrelated fixups after the zeroed stub section, then re-sign ad hoc. Without this the table was corrupted at load. - LTO-safe metadata location: the entry section carries a meta record whose relocations hold the addresses of the symbol-index pointer and count globals; LTO internalization strips those names from the symbol table but relocations always resolve. Runtime skips the meta rows (pc==0 / symbolID==0). - Idempotence guard (already-rewritten binaries are left alone). Runtime fixes that surfaced during validation: - materializePrebuiltEntries is now two-phase so concurrent losers wait for the winner's store instead of reading a nil entries slice. - pcLineFrameForPC rejects nearest-below sites whose entry is unresolved when the caller knows the function entry, instead of leaking a neighboring function's file/line. Validation: macOS cl (full) + test/go + LLDB 194/194; Linux test/go TestRuntime suite; probes on both platforms report entries=prebuilt with first-FuncForPC at 7-21µs (Linux) from 13ms on the original baseline, and LTO builds drop 8-9.5k inline copies. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…table On Mach-O, pointer slots that name exported functions — every __llgo_stub.* wrapper and any exported Go function — are emitted as chained-fixup BIND nodes, not rebases. The rewriter only decoded rebase nodes, so all stub records (and some entry records) were dropped as unowned and never reached the prebuilt ftab; FuncForPC on function values silently fell back to dladdr (~6µs per fresh pc on darwin). - Parse the LC_DYLD_CHAINED_FIXUPS imports table and resolve bind ordinals to their in-image definitions. - Match canonical owners against the record symbolID with underscore normalization (debug/macho's suffix-shared string table can surface one mangling underscore more or less than the source-level name). - Splice the prebuilt header's base slot back into the fixup chain as a live rebase node: dyld writes the slid text base at load, so the runtime reads a ready runtime PC with no slide arithmetic (non-PIE ELF link-time values already equal runtime addresses). - LLGO_PCLNPOST=0 escape hatch keeps first-use construction. Fresh-pc FuncForPC slow path: darwin 6-8µs -> 1.2-1.7µs, linux 6.8µs -> 0.5µs; first-in-process lookup: darwin ~32µs -> ~14µs, linux ~6.8µs -> ~4µs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Pure-compute probes (recursive fib, JSON round-trip, sort.Ints, map churn) with no runtime introspection, so one harness run covers both the introspection extremes and what the funcinfo machinery costs code that never asks for it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Go's pclntab pages are touched by its own runtime (traceback, GC) long before user code queries it, so its first FuncForPC never pays page-in. Mirror that: when the prebuilt table is present, init adopts it (zero-copy, sub-µs), touches the pages the lookup path reads (blob, funcinfo records, string offsets, strings), runs one synthetic lookup to warm the code paths, and write-warms the FuncForPC cache pages. First-in-process FuncForPC: darwin ~17µs -> ~2.8µs, linux ~6.6µs -> ~1.0µs. Startup cost is page-count-bound (tens of µs on stdlib-sized tables, invisible next to ~3ms process startup; hello-world medians unchanged). Non-prebuilt binaries stay fully lazy: first-use construction allocates, which has no place in init, and programs that never introspect pay nothing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
-depths generates deep_<N> scenarios at configurable call depths; -bigsizes generates bigfunc scenarios (funcs x statements) whose large bodies stress statement-level pcline density, mid-function pc symbolization, and ordinary performance of big method bodies. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Blob overflow: function-value stubs can double the row count, and at ~9k functions the prebuilt blob no longer fit the entry section, so the rewrite silently fell back to first-use construction (cold.FirstFuncForPC 96x96 non-LTO: 2.4ms). On overflow, retry with function entries only — stub pcs degrade to dladdr, real entries keep the prebuilt table. - FuncForPC cache thrash: the set-associative pc cache holds 4k entries; batch workloads over 9k+ distinct functions evicted constantly and paid the string-materializing slow path on every call (multipkg.FuncForPCMany 96x96: 8-11ms vs Go 172µs). Add a per-ftab-row *Func cache for exact-entry lookups, so batch lookups are O(binary search) after the first pass at any scale. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…erflow
Function-value stubs can push the row count past what the entry section
holds (~9k functions with taken addresses). Instead of dropping stub
rows, write the full blob into the (larger) stub section and leave a
32-byte redirect header ("LLGOFTB2" + a live-relocation pointer) in the
entry section; the runtime follows it and adopts the same zero-copy
view. Function-value lookups keep the prebuilt table at any scale
instead of degrading to dladdr.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
funcForPCSlow treated any unaligned pc as a shadow-stack synthetic marker. arm64 function entries are always 4-aligned so this never fired, but amd64 function and stub entries need not be: an unaligned function-value pc skipped the prebuilt exact-entry path entirely and fell through to nearest-below symbolization, reporting the previous function's name (test/go TestRuntimeLineInfoAndStack on ubuntu CI, "bad function value func: main.renamedPC"). Hoist the prebuilt exact-entry + per-row-cache lookup ahead of the alignment heuristic; a genuine synthetic pc just misses the cheap search and proceeds as before. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The overflow fallback dropped stub rows to fit the entry section. That leaves pc ranges the table claims to cover but does not: a function value whose stub falls in a gap resolves nearest-below to the previous function and silently returns the wrong name — exactly what ubuntu CI caught (amd64 --icf=safe layouts overflow by a few hundred bytes, and non-PIE ELF dladdr cannot rescue). If the blob fits neither the entry section nor the (larger) stub section, skip the rewrite entirely: first-use construction is slower but covers every record. Reproduced and verified on linux/amd64 (qemu): the stub pc had no exact row and nearest-below returned the neighbouring function's name. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…rgery Fabricated fixtures make the IO paths testable in-process: a minimal ELF exercises load/Rewrite end to end (in-place, stub-section spill, and the overflow fallback that must leave the binary untouched), and a synthetic Mach-O image drives the chained-fixup chain surgery (remove+splice, empty-page insert, unconsumed-insert error). Package coverage 16% -> 69%. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
cpunion
force-pushed
the
codex/pclntab-linkphase-p1
branch
from
1a9ca68 to
aa4ef20
Compare
A fabricated Mach-O (segments, sections, symtab, chained-fixup imports and an empty page chain) drives load, bind-target resolution, record decoding and both Rewrite outcomes (in-place and stub-section spill) end to end. codesign now runs only when the input carries LC_CODE_SIGNATURE: real lld executables always do, unsigned inputs need no signature and codesign rejects them. Also cover asmQuoteELFSymbol, the empty-table initializers and the Rewrite error paths. Package coverage: pclnpost 69% -> 86%. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #2012, implementing Stage 2 of the proposal in #2004: link-phase
ftab/findfunctabgeneration, perdoc/design/pclntab-linkphase.md(in this branch). P1 (analysis), P2 (automatic write-back + zero-copy runtime adoption) and P3 (Mach-O bind-record resolution, startup pre-warm, scale hardening) are complete; everyllgo-linked executable on linux/darwin now ships a prebuilt function table that is adopted zero-copy and pre-warmed at startup.How it works
linkMainPkg,internal/buildrunsinternal/pclnpost.Rewriteon the executable: parse the funcinfo entry/stub site sections, identify canonical records by FNV (a record survives when its anchor's owning symbol hashes to its symbolID, or is that symbol's__llgo_stub.wrapper — LTO inline copies fail this test exactly), sort, build the findfunctab, and rewrite the entry section in place (header +{entryOff, funcIndex}ftab + buckets), voiding the merged stub section. Any failure degrades silently to runtime: add Go-style funcinfo find index #2012's first-use construction (LLGO_PCLNPOST=0forces that path).__llgo_stub.*wrapper and any exported Go function — are chained-fixup BIND nodes, not rebases, even though they bind back into the same image. The rewriter resolves them through theLC_DYLD_CHAINED_FIXUPSimports table. Before this, all stub records were dropped as unowned, soFuncForPCon a function value silently fell back to dladdr (~6µs per fresh pc) on darwin — the real cause of the "mac cold gap" previously attributed to re-signed-binary page validation.FuncForPC: darwin ~17µs → ~2.8µs, linux ~6.6µs → ~1.0µs. Hello-world startup medians are unchanged; non-prebuilt binaries stay fully lazy.LLGOFTB2redirect header (live-relocation pointer); rows are never dropped.Full benchmark matrix
benchmark/runtime_funcinfo(committed in this branch, now covering hot/deep/multipkg/cold/stdlib and aplainordinary-code scenario), 576 target functions (24 pkgs × 24 methods), 5 runs, cellsbest/trimmed avg.main= #2012's merge base (itsmain+ltobinaries fail at runtime on macOS — observed, pre-existing). Hot paths are expected to match #2012 (same index once warm); this PR's deltas are thecold.First*rows, function-value lookups, and LTO table integrity.macOS arm64
Linux arm64 (container)
Fresh-pc slow-path lookups (function values, per-pc, split-timing probe)
The headline P3 effect.
FuncForPC(reflect.ValueOf(fn).Pointer()) + Name()on a pc not yet cached, same probe built with both toolchains:Go's per-fresh-pc cost is near-zero because
FuncForPC/Name()return zero-copy views into pclntab; LLGo still materializes name/file strings per function (three small allocations) — that remaining 0.5–1.7µs is the P4 zero-copy-name work, not lookup cost. History for maccold.FirstFuncForPC: 13ms → 35–50µs (#2012) → 32.6µs (P2) → 15.9–18.5µs (bind fix) → ~3–5µs (pre-warm).Scale benchmarks (packages × methods, call depth, big methods)
benchmark/runtime_funcinfogained three scale dimensions (-scales,-depths,-bigsizes); the sweep below (3 runs, best) found and fixed three scale cliffs, all now covered in this PR:cold.FirstFuncForPC96×96 linux non-LTO: 2.4ms). Fixed by spilling the full blob into the (larger) stub section behind a 32-byteLLGOFTB2redirect header with a live-relocation pointer; every row keeps the prebuilt table at any scale. (cold.FirstFuncForPC: 2.4ms → 4.3µs.)multipkg.FuncForPCMany96×96: 8–19ms vs Go 172–180µs). Fixed with a per-ftab-row*Funccache: batch lookups are O(index search) after the first pass. (mac 96×96: 18.6ms → 364µs non-LTO, 147µs +LTO — the LTO cell beats Go's 179µs; mac 48×48: 20µs vs Go 46µs.)cold.FirstFuncForPCis now 3–5µs on both platforms (Go: 2–3µs), andcold.FirstCaller0/FirstFileLinebeat Go throughout.Big-method scenario (
bigfunc, funcs × statements)Large bodies are where the compact pcline index shines — Go re-decodes its pcvalue tables per query, LLGo does an index lookup:
(
maincannot run this probe at all — mid-body pc symbolization did not exist before this line of work.)Honest remaining gaps at scale (all quantified, none regressions of this PR)
main. This is the Stage 5 unwinder motivation, now quantified.bigfunc.Work's 13.7× gap has the same cause (verified:LLGO_FUNCINFO_SITES=0is equivalent, so it is not the site records).FirstFileLineafter spill 96×96: ~400µs once per process;FirstCallersFrameslinux ~55µs) — P4 prebuilt pcline table.Ordinary-code performance (
plainscenario, no runtime introspection)Pure compute, no introspection (
plain.fib30reads its depth from the environment so full LTO cannot fold it away). This PR inherits #2012's characteristics unchanged — the rewrite only edits metadata sections:macOS
Linux
2016tracks2012within noise on every metric (±0–2%); vsmainthe only consistent delta isfib30(+20%, both funcinfo branches equally — body-embedded site asm shifting inline/layout decisions in deep recursion).Narrow A/B via
LLGO_FUNCINFO_SITES=0(documented in #2012) still holds: the tables are free at runtime; the ±% vsmaincomes from body-embedded site asm shifting inline/layout decisions, and is bidirectional. Against Go, ordinary-code deltas are dominated by the LLGo baseline itself (identical onmain).Binary size (identical between 2012 and 2016 — in-place rewrite does not change file size)
Build time: llgo stdlib 18–20s (non-LTO) / 20–24s (+LTO) on both platforms; the post-link rewrite itself is well under a second per binary.
LTO table integrity
LTO inlining duplicates body-embedded records into host functions; FNV canonical detection removes them exactly (~8.0k inline copies dropped per LTO probe at this scale) — eliminating both misattribution risk and runtime table pollution. With P3's bind resolution the mac tables also gained all
__llgo_stub.*and exported-function records (probe ftab: 1.9k → 3.3k rows).¹ LLGo statement/call-site granularity vs Go's dense per-instruction pcvalue — faster at this granularity, not full pcvalue semantics (P4).
²
cold.FirstCallersFrameson Linux measures the pcline table's first-use build, which this PR does not cover (P4); it dominates whicheverFirst*window triggers it.³ Measured before the startup pre-warm landed; the scale runs below (with pre-warm) show 3–5µs at every size on both platforms.
Validation
go test ./cl(full, 460s) ok,test/gook,_lldb/runtest.sh194/194 (0 failed).test/gook; end-to-end probes (entries=prebuilt stubs=prebuilt, correct name/file/line, ±LTO).cl+test/go+internal/build+internal/pclnpost+ LLDB suite; Linuxtest/go; 96×96 spill probe end-to-end (30.4k-row table adopted through the redirect header, names/lines correct).Staging status (per #2004 / design doc)
!pcsectionsas the site-record mechanism; section shrinking for the size delta.bigfunc.Work/stdlib.Work.Depends on #2012 (branched from it; will rebase once it merges).
🤖 Generated with Claude Code