Evidence-Anchor Index

All addresses on this page apply to libtpu.so build-id 89edbbe81c5b328a958fe628a9f2207d, from the libtpu-0.0.40-cp314 wheel. The binary is not stripped: every 0x… here resolves to a demangled C++ symbol in the IDA function table, and .text/.rodata/.lrodata/.data.rel.ro map VMA == file offset. Other builds will differ.

Abstract

This is the wiki's reverse-lookup index: a flat, address-sorted table of the binary anchors that recur across the deep pages, each mapped back to the page that explains it. It exists for one workflow — you are in IDA, your cursor lands on 0x1c89fba0, and you want the prose that documents it. Scan the master table, find the row, follow the link. It is the inverse of subsystem-map (which goes subsystem → address band) and of front/codename-cheatsheet (which goes codename → facts): both of those collect anchors forward; this page is the flat address → page spine that ties them together.

The index is deliberately not exhaustive. The binary has 884,832 functions; this page carries only the ~60 genuinely cross-cutting anchors — the entry points, factory functions, cost tables, target accessors, and data sections that are cited on three or more pages and that a reader is realistically likely to hit cold. Single-page locals (the thousands of _GLOBAL__N_ helpers, per-opcode handlers, ICF duplicates) are documented in place on their owning page and are not duplicated here. The selection bias is toward addresses that a reimplementer needs to recognise to orient inside the binary at all.

Every row was verified both ways before it was admitted: (a) the address resolves to the named symbol in the IDA function table (…_function_addresses.json) or, for data anchors, to a section/symbol the owning page pins; and (b) the named owning page exists and actually cites the address. Where a label in circulation does not survive that check, a > **CORRECTION —** callout records it instead of a silent fix. Confidence reflects the binding (address ↔ page), not the underlying RE claim, which the owning page grades on its own.

For reimplementation, the contract this page serves is:

• Orientation — given a raw VA, recover the symbol, its role, and the page that documents the algorithm behind it.
• Provenance — every binding is independently re-checkable: the symbol is in the function table, the citation is in the named src/ page.
• Scope honesty — the index covers the cross-cutting spine, not the long tail; it tells you what it does not index.

Master Anchor Index

One row per cross-cutting anchor, sorted by ascending VA. What it is is a one-line role; Owning page(s) links the page(s) that document the algorithm or layout; Confidence grades the address ↔ page binding. Subsystem-grouped detail follows in the sections below.

GOTCHA — the five anchors that open the table (0x1c60480, 0x3366d90, 0x84a0000, 0xb438aec, 0xbe8af30) sort below .text's base 0xe63c000 even though some are 8 hex digits and look "high". They are data: 0x1c60480/0x3366d90 in .lrodata, 0x84a0000 in .rodata, 0xb438aec/0xbe8af30 in .rodata/protodesc_cold. The large-code-model l-flagged sections (.lrodata 0x01884a00–0x084931d0) live in a low band reached by movabs, not by RIP-relative lea. Do not assume a small-looking VA is interior to an early function; check the section first.

NOTE — the master table is the authoritative spine. The subsystem sections below restate the same anchors grouped by role with extra context; they add no new bindings. When the two disagree, the master table wins.

How to use the index

The intended workflow is single-VA lookup. Given an address in IDA:

1. Round to the function head. The table keys on the symbol's entry VA. If your cursor is at 0xf874223, the owning function is the largest table key ≤ your VA — here CreatePjrtApi @ 0xf874160. The index does not list interior addresses; use the disassembly's function boundary to find the head, then look up the head.
2. Read the band, not just the row. subsystem-map pins each address band to a subsystem; if your VA is between two indexed rows, the band still tells you which subsystem section to skim. PJRT/lifecycle is 0xe6…–0xf8…; the cost-model/target/jellyfish core is 0x1c8…–0x1d7…; ISA encoders and per-gen factories are 0x1e8…–0x20b…; the data sections are below 0xc2… and above 0x214….
3. Follow the first owning link. The first page in Owning page(s) is the canonical owner — the page whose subject is this anchor. The second is a high-value co-citing page (a caller, a sibling, or a catalog) for context.
4. For a data VA, expect a range. Data anchors (.rodata, .lrodata, protodesc_cold, .init_array, .data.rel.ro) are cited as [start, end) spans on their owning pages; a single VA inside the span resolves to the section, not a symbol. binary-layout is the authority for the exact bounds.

Scope and selection

An anchor earns a row only if it is cross-cutting: cited on three or more src/ pages, or an exported entry point, or a data section that multiple subsystems reference. That rule deliberately excludes three large categories a reader will still meet in IDA — and the index says so rather than pretending to be complete:

• Per-page locals. The _GLOBAL__N_ helpers, lambda bodies, and single-use rewriters that one page documents in place. They are findable from that page; duplicating them here would bury the spine.
• ICF duplicates. Identical-code-folding produces many byte-identical copies of small functions and data tables (the kDeviceTypeInfo story is the canonical example: one main copy at 0x1c60480, 13 data duplicates). The index lists only the canonical copy.
• Per-opcode / per-arm leaves. The 461 LLO opcodes, the AutoProto message arms, the InstBits rows — these are tables, indexed once by the table anchor (opcode_info @ 0x223a1320, InstBits @ 0x3366d90), not row by row.

A VA that misses the index is therefore not undocumented; it is either interior to an indexed function, a per-page local on its owning page, or a member of an indexed table. Round to the head and re-look-up before concluding a gap.

PJRT and Lifecycle Anchors

These are the addresses a reader hits first: the loader entry points, the static-constructor machinery, and the lazily-built API singleton. They cluster low (0xe6…–0xf8…) with the static-init data parked high in .init_array/.lbss.

QUIRK — the only required PJRT export is GetPjrtApi @ 0xe6a83a0, but it does almost nothing: it tail-calls GetTpuPjrtApi @ 0xe6aa440, which lazily runs CreatePjrtApi @ 0xf874160 exactly once and parks the result in the static-local pjrt_api @ 0x227ba840. A reimplementer chasing "where is the API table built" will bounce through three addresses in three subsystems before reaching the assembly site.

Codec and Per-Generation Anchors

Per-version factories and the ISA encoders. These resolve a TpuVersion/DeviceType to a codec, a codename string, or a 32-byte encoded bundle, and sit in the upper .text band (0x1e8…–0x20b…) alongside the instruction-bit and opcode-property data tables.

GOTCHA — the seed shorthand "DefaultsForVersion@0x20b1b040" resolves to tpu::TpuChipParts::DefaultsForVersion, not a free function. A reimplementer must enter it through the TpuChipParts aggregate; there is no standalone DefaultsForVersion symbol at that VA.

Cost-Model Anchors

The cost-model spine: the latency/cycle/resource tables and accumulators the scheduler queries. They live in a tight jellyfish/viperfish band (0x1c89…–0x1c8a…) with the priced LUT data down in .rodata near 0xb438….

Target and Memory Anchors

The jellyfish::Target accessors that a reimplementer hits constantly — lane count, cores-per-chip, reserved sync-flag numbers — plus the memory-space stringifier. All in the 0x1d6… band.

NOTE — Target::Init @ 0x1d60fc20 is the constructor that populates the object every other Target:: accessor reads from; the accessors at 0x1d60f4xx are trivial getters over fields set there. Trace data-flow from Init, not from the getters.

Barrier, Collective, and Routing Anchors

Synchronisation and collective-geometry machinery: barrier-config solvers, the tree-barrier core enumerator, the remote vsync encoder, and the twisted-torus replica-group geometry. Spread across 0x109…, 0x133…–0x137…, and 0x1c6…–0x1d5….

Compiler, Scheduler, and Runtime Anchors

Pipeline registration, the latency-hiding scheduler core, flag/comp-env plumbing, and the runtime execute path. The compiler/config code sits in the 0xf8…/0x1d7…/0x1e6… bands; the scheduler and runtime in 0x10…–0x13….

Profiling and Data-Section Anchors

The trace pipeline factory, the per-DeviceType info table, and the large read-only data sections a reader will scroll into without a function under the cursor. These are the anchors most likely to be cited as ranges rather than single VAs.

QUIRK — kDeviceTypeInfo @ 0x1c60480 is .lrodata (perm 4, read-only-no-write) with zero .rela.dyn entries across [0x1c60480, 0x1c64d48) — it is frozen at link time and has no runtime producer. The 13 byte-identical copies elsewhere in .lrodata are ICF data duplicates, not independent tables; index only the main copy.

CORRECTION (ANCHOR-1) — the data anchors 0x84a0000 (name pool), 0xb438aec (resLUT), 0x223a1320 (opcode_info), 0x3366d90 (InstBits), 0x224bf798 (filewrapper_toc), 0x227ba840 (pjrt_api), 0x215f26f0/0x215f8190 (.init_array), and 0x22048b30 (.data.rel.ro end) do not resolve to symbols in …_function_addresses.json — that file lists code functions only. They are data/section anchors and were verified instead against the owning page's section/symbol citation (and, for kDeviceTypeInfo and pjrt_api, against named symbols _ZN5xprofL15kDeviceTypeInfoE and _ZL7toc_ptr). An address that fails the function-table lookup is not therefore invalid; check whether the owning page pins it as data before treating a miss as a defect.

Cross-References

• Subsystem Map — the forward index: address band → subsystem; pairs with this flat reverse index
• Codename Cheatsheet — codename → per-gen facts; many anchors here are per-gen factory functions cited there
• Cross-Reference Graph — page → page link graph; use it to walk from an owning page to its neighbours
• Symbol Namespace Index — namespace census (xla::jellyfish, xprof::tpu, …) behind the symbols indexed here
• Binary Layout — full segment/section table; the authority for every data-section range cited above
• Per-Gen Comparison Matrix — collects the per-version factory anchors (TpuCodec::Create, DefaultsForVersion, TpuVersionToString) into one table
• Get-PjrtApi Thunk — the three-hop PJRT entry path the lifecycle anchors trace
• PJRT API-Vtable Reconstruction — the 140-slot table CreatePjrtApi fills and the pjrt_api singleton caches