开放边境寄存器
本页上的所有地址、计数和 sidecar 数字均适用于
libtpu-0.0.40-cp314轮中的libtpu.so(build-id md589edbbe81c5b328a958fe628a9f2207d，781,691,048 字节，ELF x86-64，未剥离)。其他版本会有所不同。
摘要
本书中的每一页都断言有关未剥离的 745 MB 二进制文件的信息，并且只有当它陈述其自身边缘与其内部一样精确时，重构才是可审计的。这个附录就是那个边缘：尚未完全解决的问题的诚实目录，作为实时记录而不是免责声明保存。它与 wiki 的其余部分相反 - 每个条目不是“这里是算法”，而是“这里是问题，这里正是关闭它的证据，这里是拥有答案的页面”。
边界分为五类，其区别很重要，因为它们以不同的方式关闭。 反编译墙是 Hex-Rays 拒绝解除的功能 - 大多数是导入存根，没有主体可恢复，剩余的 ~21 是手动反汇编通道将关闭的真实代码。 依赖于硬件的事实是静态分析在结构上无法确认的值，因为它们仅存在于供电的 TPU 上：运行时填充的框架 vtable 插槽、实时遥测计数器、根据设备状态解析的标志默认值。 每代数据差距是旧代号的常量，以一种原型形式提供，但不是另一种形式。 推断链接项是 wiki 通过名称家族协议追踪的边缘，但没有在叶子处进行字节确认。 命名的开放问题是五个具体任务(#1092、#1096、#1171 和 P-3-478..482 SparseCore/DMA 集群)；恢复过程直接从反编译中关闭了 #1092/#1096/#1171 三重奏(两个表面 CORRECTION)，随后的定向反汇编批处理关闭了 P-3-478..482 集群(三个字节跟踪，一个确认为非边缘)，因此所有五个都已解决。
寄存器只有同时也是已关闭项目的墓地时才是可信的。几个曾经开放的声明不仅被悬而未决——它们被后来的分析“推翻”了，这些 CORRECTION 在这里被记录为“通过更正关闭”，以证明寄存器反映了当前状态，而不是最初的临时假设。 Trailing-zstd blob、“walrus”pass driver 和 naive demangle-rate count 都是有效的示例。
对于审核员来说，此页面的契约是：
- 确切的失败层 - 516个反编译拒绝和7,915个分析问题，分解到结构原因，以便读者知道哪些是知识差距，哪些是噪音。
- 每个项目的可封闭性等级 - 置信度列，在此页面上唯一，对可以如何自信地缩小差距以及通过什么证据进行评分，而不是当前声明的置信度。
- 每个项目的所属页面 - 每个开放问题都会路由到吸收其解决方案的页面，因此关闭边界是一个可导航的任务列表，而不是一个愿望。
| 反编译失败 | 516(无 cfunc) — 由 方法论-深度 所有 |
| —导入/数据存根 | 486(0x22860108–0x228611xx thunk band；不是知识差距) |
| —手写汇编 | 9(BoringSSL bignum/MD5、dnnl JIT 内核；不存在 C 源代码) |
| ——模板/代码生成巨头 | ~21(正品残墙) |
| 分析问题 | 7,915(6种；final 4188占主导地位) |
| 命名的开放任务 | P-3-478..482 SC/DMA 集群 — #1092/#1096/#1171 三重奏在稍后的过程中恢复(现已关闭) |
| 因更正而关闭 | Trailing-zstd blob · “walrus” · demangle-rate · 每代几何源 |
| 置信列语义 | 间隙的可闭合性，当前索赔的不确定性 |
前沿寄存器
下表是主索引。每一行是一个未清项目； 置信度列对给定阻塞证据列中指定的证据来“缩小”差距的信心程度进行评分 - HIGH 表示有界手动传递已识别的地址来关闭它，LOW 意味着关闭它需要二进制文件不包含的证据(受电设备，较新的版本)。读取 CLOSED 的行被保留以表明寄存器处于活动状态；它们的详细信息位于 §因更正而关闭 部分。
| 未清项目 | 类别 | 阻止证据以关闭它 | 所属页面 |
|---|---|---|---|
~21 个模板/代码生成函数，没有 cfunc | 反编译墙 | 指定地址的手动解除；提高电梯预算 | 方法论-深度 |
| dnnl JIT + BoringSSL asm 存根不可恢复为 C | 反编译墙 | None — 没有 C 源代码的汇编；阅读disasm | 嵌入式库图集 |
PJRT vtable 插槽由 Create 的框架填充 | 取决于硬件 | TPU 上的实时 PJRT_Client_Create 跟踪 | 客户端和设备 |
FLAGS_enable_runtime_uptime_telemetry 实时值 | 取决于硬件 | 设备上运行时；遥测数据被读取，而不是存储 | 流执行器 pjrt 适配器 |
| 根据设备状态解析的默认标志 | 取决于硬件 | 设备驻留配置；静态默认可能是哨兵 | 标志-目录-完整 |
chip_config(驾驶员侧)与 chip_parts(几何)拆分 | 已关闭(已恢复) | 已恢复：kChipConfigAliases (0x2200b8b0) 是由 TpuVersion {2,3,4,5}(变体 "default")键入的静态 4 条目 flat_map； v4/v5 共享一个别名子映射。每个 TpuVersion 消费者的划分是完全静态的，不是设备探测的 | 每代比较矩阵 每个嵌入的 blob 中都不存在 |
issue_latency_cycle_count | 每代差距 | chip_parts 填充字段 4 的构建 | 每代比较矩阵 每个嵌入的 blob 中都不存在 |
834 流操作每叶 (pattern,verb,dtype,space) 操作码 | 关闭(阴性结果) | 不存在每叶静态表：槽命令是在 SparseCoreStreamEncoder::Encode (0x1eb9b4c0) 中从 4 个正交原始位字段运行时组装的 - 形式(位 53–58：线性 0x3b/跨步 0x3a/间接0x39)，动词 (dword[+0x18]>>9)&7，dtype (>>0xc)&1，内存空间 (qword[+0x10]>>0x2f)&7。打开 INFERRED → 经过验证的组合非每叶 | llvmtpu-内在表 |
| 890 默认构建器操作的精确数量+结果谓词 | RECOVERED(元数)/NEGATIVE(谓词) | 从每个操作的损坏的 Op<…OneResult/ZeroResults…NOperands<Lj N>…> 特征包中读取的 Arity 字节 - (#res,#operands) 形状为 1356 个中的 1060 个，完整的人口普查列表。结果谓词：MLIR 层没有每操作 Vreg/Mask/Scalar/Ptr — 所有通用 OneTypedResult<mlir::Type> + 一个共享 isCompatibleOuterType | llvmtpu-内在表 |
每固有 LLVM IntrProperties 位 | 已恢复 | 解码：set = IntrinsicsToAttributesMap[ID−1] >> 9 (@0x416fb30)；所有 12 个 fn-attr 集均已字节解码、每集精确普查(总计为 1356)、16 叶样本字节验证；其他 1340 个叶子的每一叶都是确定性的半字查找 | llvmtpu-内在表 |
#1092 结构化稀疏时隙编码 | 已关闭(已恢复) | 已恢复：没有专用稀疏捆绑槽 - 稀疏性在打包的 MXU 操作数布局中运行(SparsityConfig，1:N 限制，SME 外积门) | 插槽稀疏-v5plus |
#1096 每代 NOP 规范模板 | 已关闭(已恢复) | 恢复：两个正交无操作 — 空槽谓词 kNeverExecute=31 填充 + 操作码空间全 1 NOP(CORRECTION NOP-1：默认捆绑包停止) | nop-规范 |
#1171 TpuVersion 感知标志前缀调度 | 已关闭(已恢复) | 已恢复：代号前缀标志无条件注册并应用 gen-blind (CORRECTION DISPATCH-1)；活动生成器仅选择数据/编解码器，而不选择标志门控 | 标志前缀调度 |
P-3-478 InitializeOnScs 查找回调边缘 | 已关闭(已恢复) | 恢复：InitializeOnScs (0x1337aa60) 将核心索引然后 call *0x98(%rbx) 折叠到 ExplicitRingRecord (0x133a9a40) / ExplicitAllToAllRingRecord (0x133a94a0)，写入(ordinal, next_chip, reorder) 转策略 +0x58/+0x60/+0x78 | 张量核势垒 |
P-3-480 LatencyTable::Create(TpuVersion) factory tail | 已关闭（已恢复） | 已恢复：不是 cmp switch，而是由五个 static-init TU initializer 填充的平面 ordinal-indexed inlined_vector<AnyInvocable> registry（0x225799f8）；registry[version](entry) 通过 call *0x18，per-gen invoker→ctor 已按字节追踪 | 循环表系列 |
P-3-481 SetLatchIndices 每代超限握手 | 已关闭(已恢复) | 恢复：门为 idx==0 && !GainLatchModeHasOverrunChecks(latch_mode)(vtable +0x358)；只有 ViperfishTarget::HasMsrOverrunChecks (0x1d49aac0 = mov $1) 返回 TRUE，因此只有 v5 索引第一个锁存器 | 锁存器分配溢出 |
P-3-482 cmem-负载/稀疏 DMA 边缘 | 关闭(非边缘) | 非边缘：EmitVectorCmemLoad (0x14120a40) 仅调用 SlotMap 绑定器 — 无 DMA/稀疏被调用者。稀疏性是 v5+ SparseCore (gxc::*)； v4 pxc::isa 无稀疏编解码器；两者从不同时发生 | 插槽-cmem-负载-pf |
| 尾随 zstd blob → 每个代号常量 | 已关闭 | — 翻转：不存在斑点 | 尾随-zstd-blob |
| “海象”通管道驱动程序 | 已关闭 | — 翻转：二进制中出现零次 | 术语表 |
naive _Z-前缀拆解率(98%) | 已关闭 | — 推翻：现场支持率为 93.0% | 方法论-深度 |
7 illegal_addr 分析问题 | 已关闭(已分类) | — 分类：6 是 gRPC 过滤器尾声中故意的 call *0x10 近空陷阱，1 是 .rodata 跳转表 IDA 未对齐；没有重新定位，没有段外数据引用 | §7个非法地址异常 |
注意 — 此页面上的“置信度”列故意“不是”证据公约 为本书其余部分定义的四级行为量表。在这里，它对缩小差距的可处理性进行评分：
HIGH/MEDIUM项目是有界静态工作，该语料库已包含其输入；LOW物品需要动力设备或不同的构造；CERTAIN (won't improve)物品位于其永久楼层。
反编译墙
用途
头条新闻是 516 个函数，Hex-Rays 没有返回 cfunc — 884,832 个恢复函数的 0.058%。天真的读起来，“516个函数没有反编译”听起来像是516个函数的知识鸿沟。它不是。 方法论-深度差距审计拥有完整的分类法；该部分的工作是说明 516 人中哪些是“前沿”(值得重新攻击)以及哪些是永久在场上的。
三大结构性原因
按地址带和分解名称对 516 进行的细分将每个拒绝放入三个桶之一：
516 decompilation refusals (no cfunc)
├─ 486 import / data stubs 0x22860108–0x228611xx (one shard)
│ strlen · free · getenv · abort · __cxa_finalize · __tls_get_addr
│ MallocExtension_Internal_* · sched_getcpu · eventfd
│ → PLT/GOT-style thunks; no local body exists to lift. NOT a gap.
├─ 9 hand-written assembly 0x206ee040–0x2071e720 · 0x1b012c00 …
│ bn_sqr8x_mont · bn_power5_nohw · bn_mulx4x_mont_gather5 · md5_sha1_final
│ dnnl jit_avx512/jit_uni convolution kernels
│ → assembly with no C source; read the disasm, never the cfunc. Floor.
└─ ~21 template / codegen giants the genuine residual wall
mlir::Dialect::addOperations<…1000+ TF ops…> @ 0xfedc180
xla::jellyfish::ReduceEmitter::EmitReduction @ 0x13e16240
llvm::LiveIntervals::computeVirtRegInterval @ 0x18e601e0
llvm::X86II::getMemoryOperandNo · AtomicExpandImpl::run · RegAllocEvictModel
xla::{viperfish,ghostlite}::*Performance ctors · DummyAlias*Printer
→ real code Hex-Rays declined on lift budget; a manual pass closes these.明白了 — 主要的 486 个是
0x2286xxxx中单个连续分片中的导入 thunk。如果读者将“516 个失败”视为 516 个缺失函数，则夸大了大约 24 倍的差距。实际的前沿是 ~21 个 template/codegen 函数； 486 个 thunk 通过它们的符号名称简单解析，9 个 ASM 存根位于其永久层。引用 ~21，而不是 516，作为可恢复的墙。
什么关闭每个桶
| 铲斗 | 计数 | 关闭者 |
|---|---|---|
| 导入/数据存根 | 486 | 已按交易品种名称关闭；无需反编译 |
| 手写汇编 | 9 | 阅读反汇编； cfunc永远不会存在 |
| 模板 / codegen Giants | ~21 | 手动解除指定地址传递；预算增加的一些电梯 |
QUIRK — 最大的单一拒绝，
0xfedc180处的mlir::Dialect::addOperations<…>，是一个注册整个 TensorFlow MLIR 操作集的 C++ 调用 - 超过一千个操作类作为单个语句中的模板参数。它在算法上并不有趣；恢复它会产生一个平面注册列表，而不是逻辑。它位于边界只是因为反编译器拒绝它，而不是因为重新实现器需要它的主体。jellyfish::ReduceEmitter::EmitReduction拒绝(0x13e16240)是相反的——深度嵌套的btree_map签名背后真正有趣的减少排放逻辑——并且是一个值得有针对性的手动通过的模板爆炸拒绝。该过程已完成：0x13e16240–0x13e16720的窗口反汇编将其恢复为细轴调度程序(验证 → 两个轴位 → 尾调用五个专用发射器之一)，并在 融合模式§ReduceEmitter::EmitReduction 中编写。因此，剩余墙的 TPU-IP 一半被关闭 - 剩下的是注册样板 (addOperations) 和上游 LLVM/XLA 巨人，其逻辑是可恢复的，但不是 TPU 特定的。
零输出层 — 5 个命名地址(已关闭)
516“无 cfunc”计数是 Hex-Rays 产生一些输出但没有干净的 C 树的集合。一个严格更难的子集是工件级底层：IDA 为其编写的地址根本没有反编译文件。对于libtpu.so来说，该集合恰好是五个命名地址，命名它们解决了楼层是否隐藏任何TPU IP的问题。事实并非如此——每个人都是第三方：
| 地址 | nm 符号 | 种类 | 它是什么 |
|---|---|---|---|
0x1ffb8020 | riegeli::TransposeDecoder::Parse | 代码，7,424 B | riegeli 柱状转置记录解码器(跟踪容器编解码器，riegeli-trace-container)；对于电梯预算来说太大，向上游出售 |
0x21055260 | proto2::internal::UntypedMapBase::SpaceUsedExcludingSelfLong | 代码，1,984 B | protobuf映射字段内存核算；供应给上游 |
0x206a3600 | mlkem::(anon)::fips::ensure_decap_self_test()::$_0::__invoke | 代码，很简单 | ML-KEM FIPS 开盖自测 lambda — call decap_self_test; test eax; ret； BoringSSL 后量子加密 |
0x206a8000 | (无 — 0x1000 到 ecp_nistz256_precomputed、0x206a7000–0x206cc000，148 KB) | 数据 | NIST P-256 预先计算的 EC 点表； BoringSSL 加密常量，而不是代码 |
0x206d2690 | boringssl_self_test_fast()::kTLS10Secret | 数据 | TLS-1.0 KDF 已知答案测试秘密(字节包含文字 TLS10-KDF KAT)； BoringSSL 自检常量，不是代码 |
明白了 — 五个(
0x206a8000、0x206d2690)中的两个是数据 IDA 试图将其提升为函数 — NIST P-256 点表和 TLS KDF 测试向量 — 因此“反编译失败”是正确的结果，而不是间隙。另外三个是供应的库代码(riegeli 解码器、protobuf accountant、单行 ML-KEM 自测试)。没有一个是 TPU IP。整个 745 MB 二进制文件的工件级反编译层是两个加密 blob、两个上游库函数和一个加密自测试存根 - 确认可恢复的 TPU 表面已完全解除。
7915问题分析
第二层发布的是problems sidecar：7,915 IDA分析问题，与反编译拒绝和按类型而不是按子系统聚类不同。
| 问题类型 | 计数 | 它是什么 | 前沿？ |
|---|---|---|---|
final | 4,188 | 地址最终确定，但没有完整的流分辨率 | 否 — 分析记账 |
rolled | 1,659 | 指令已纳入先前的分析单元 | 否 — 簿记 |
disasm_problem | 942 | 字节跨度 IDA 无法干净地反汇编 | Marginal — 代码中数据边缘 |
bad_stack | 574 | 堆栈指针增量在某个点未解析 | 边际 — 影响帧恢复 |
head_problem | 545 | 指令头边界模糊 | 否 — 簿记 |
illegal_addr | 7 | 引用任何段之外的地址 | 是的 — 7 个值得一看的异常现象 |
注意 — 7,915 个问题绝大多数是分析簿记(
final+rolled+head_problem= 6,392, 81%)，而不是知识差距。前沿审计员应该追踪的唯一行是 7illegal_addr异常 - 指向每个定义段之外的引用，这通常意味着加载程序在运行时解析的重定位或真正的分析失误。它们是最容易处理的问题地板项目，下面对它们进行了全面分类。
7 个 illegal_addr 异常 — 分类(已关闭)
该元页面拥有分类，因为这七个站点是问题层项目，没有自己的子系统深层页面。七个地址中的每一个都位于可执行段的“内部”(没有一个地址是越界的作为代码地址)； IDA 标记的是，在该站点解码的操作数引用了每个 PT_LOAD 之外的地址。下面确认了两个结构性原因 - 接近空的绝对间接调用和未对齐的跳转表基加载 IDA - 不存在任何知识差距。
测量它们所依据的段框架 (readelf -lW)：
LOAD VirtAddr 0x00000000 FileSiz 0x213f25d0 Flg R E ← .text lives here (sec [21] 0x0e63c000..0x21217484)
LOAD VirtAddr 0x215f25e0 FileSiz 0x00a62bc0 Flg RW
LOAD VirtAddr 0x222551c0 FileSiz 0x0026e6a0 Flg RW
LOAD VirtAddr 0x22798c30 FileSiz 0x00021c00 Flg RW| 站点(指令地址) | 解码后的操作数 | 陷入 | 搬迁？ | 分类 |
|---|---|---|---|---|
0x20062a67 | call *0x10 (ff 14 25 10 00 00 00) | 绝对 0x10 → 无 PT_LOAD(ELF 标头间隙，低于 LOAD1 VMA 0) | 无(readelf -rW 现场为空；0x10 未修补) | 近空绝对间接调用；故意无法访问/中止融合 gRPC 过滤器尾声的尾部 |
0x2006a8a4 | call *0x10(相同7字节) | 绝对 0x10 → 无 PT_LOAD | 无 | 相同惯用法(不同过滤器融合) |
0x20070a95 | call *0x10(相同) | 绝对 0x10 → 无 PT_LOAD | 无 | 相同的成语 |
0x20074db2 | call *0x10(相同) | 绝对 0x10 → 无 PT_LOAD | 无 | 相同的成语 |
0x20079a52 | call *0x10(相同) | 绝对 0x10 → 无 PT_LOAD | 无 | 相同的成语 |
0x2007e7b5 | call *0x10(相同) | 绝对 0x10 → 无 PT_LOAD | 无 | 相同的成语 |
0xee6c96b | lea 中 lea -0x4af7817(%rip),%rsi # 0xa375158 | 桌子底座 0xa375158 → .rodata (秒 [11]，+0x1ed5158) | 不需要(RIP 相关，无动态重新定位) | 跳转表调度；标记字节位于 movslq (%rsi,%rdx,4); add %rsi,%rdx; jmp *%rdx 交换机的 lea 内部 — IDA 未能遵循计算表，基址有效 |
引用证据：
- 这六个 gRPC 站点是字节相同且唯一的。 整个
.text反汇编扫描发现ff 14 25 10 00 00 00/call *0x10编码 正好六次 - 这六个站点，没有其他地方。每个处的原始字节(文件偏移量 =.text的 VMA)：… 77 | ff 14 25 10 00 00 00 | 48 89 …。没有基址寄存器的 SIB 字节25编码 disp32-absolute 内存操作数，因此调用取消引用固定线性地址0x10。该地址位于 LOAD1 的VirtAddr 0x0映射区域的第一个代码下方(在标头间隙中)，并且不在PT_LOAD中 — 因此是illegal_addr。readelf -rW在六个指令偏移量中的任何一个处都没有列出重定位，因此加载程序永远不会重写0x10；它是一个编译时固定的近空指针，是高度模板化的grpc_core::promise_filter_detail::MapResult<…>过滤器融合组合器的无法访问/崩溃的尾部。 (grep0000000000000010时出现的R_X86_64_DTPMOD64行是 TLS 模块重定位，其 addend 列是0x10；它们的目标 VMA 是.got中的0x22048d50…，与绝对0x10的任何代码引用无关。) - absl 站点是一个跳转表，是一个不错的参考。 在
0xee6c968中，指令是lea -0x4af7817(%rip),%rsi # 0xa375158，紧随其后的是movslq (%rsi,%rdx,4),%rdx ; add %rsi,%rdx ; jmp *%rdx—absl::container_internal::raw_hash_set<…tsl::tstring…>::find_large中规范的相对偏移跳转表调度。标记的地址0xee6c96b是lea的三个字节(RIP 位移字节e9 87 50 fb)，因此 IDA 的线性扫描未对齐，然后无法解析计算出的jmp *%rdx。表基0xa375158干净地解析为.rodata(第 [11] 节，0x84a0000..0xbe8af28，偏移量+0x1ed5158)；没有任何内容超出段。这是可恢复的分析失误，而不是知识差距。
明白了 — 这七个都不是加载程序在运行时解析的重定位(上面的注释命名的第三个假设)：
readelf -rW在每个站点都是空的，唯一需要修复的候选目标 - 绝对0x10- 故意不打补丁。六个是 gRPC 模板尾声中故意的近空间接调用陷阱；一种是 IDA 误读了.rodata跳转表。所有七项均以 零 剩余间隙结束 -illegal_addr地板已完全考虑在内，无需设备上的证据。
硬件相关事实
用途
第二类前沿项目无法通过任何量的静态工作来关闭，因为该事实并不存在于二进制文件中 - 它仅存在于供电的 TPU 上。这些项目在此处精确标记，因此以后的页面不会将静态占位符视为实际值。此类别中每个项目的可关闭性置信度为 LOW：关闭它们需要一个实时设备，这超出了本书所基于的静态 RE 方法。
运行时填充框架 Vtable 插槽
libtpu.so 是一个 PJRT 插件，导出一个 C 符号 GetPjrtApi，返回一个 140 槽 PJRT_Api vtable (API & vtable 重建)。在这些插槽中，有 5 个由 CreatePjrtApi 的调用者注入，其中 4 个携带真正的 TPU 特定代码(插槽 8、15、87、103，全部为 tpu_plugin:: 命名空间)；所有这些都是静态可解析的 - tpu_plugin::PJRT_Client_Create (0xe6a8840) 的插槽 15 点，在二进制文件中得到确认。但是 Create 构建的 PJRT_Client 对象的“内容”——每个设备句柄、tpu::System* 共享指针、有线设备/内存/拓扑槽——在运行时由探测硬件填充。静态二进制文件显示构造代码(客户端和设备)；它无法显示结果对象图，因为这取决于设备枚举的核心数量以及 tpu::System::Initialize (0x1d0ae420) 发现的内容。
注意 — wiki 将
PJRT_Client_Create→GetTpuPjRtClient(0xf8008c0) →xla::TpuClient构造完全跟踪为代码。它无法跟踪的是构造后的状态：存在多少个xla::TpuDevice对象、每个TpuCoreLocation解析为什么、Semaphore的限制允许什么。这些是运行时事实。从代码路径重建客户端的重新实现者将得到正确的形状； 人口是一个实时跟踪问题。
实时遥测值
构造路径读取 FLAGS_enable_runtime_uptime_telemetry，设置后会将正常运行时间遥测合并到客户端配置中。旗帜的存在及其门是静态的；它流式传输的遥测值是没有静态表示的运行时计数器。任何描述遥测内容的页面都描述的是线路模式，而不是观察到的值。
标志默认值可解决设备上的问题
旗帜目录 从二进制文件中恢复每个标志的静态默认值。标志子集带有静态 sentinel 默认值，运行时会在启动时覆盖设备状态(例如 -1/0 占位符，表示“询问硬件”)。对于这些，静态默认值不是有效的默认值。前沿项目是：哪些标志携带哨兵，以及每个标志解析什么设备状态规则。这只能通过设备(即 LOW)关闭。
明白了 — 将标志的静态默认值读取为其有效默认值的重新实现者将错误配置其实际值是设备派生的任何标志。静态目录关于“二进制文件存储的内容”是正确的；它对运行时替代什么保持沉默。将任何看起来像哨兵的默认值视为未解决，直到在硬件上得到确认。
每代数据差距
用途
较旧的代号常量是一个经常被假设的差距，结果是大部分已关闭 - 寄存器的工作是准确地说出这一点，而不是留下模糊的“较早的一代可能不完整”。真正的残差很窄。
已经关闭的内容
暗示的差距 - “旧代号仅以 chip_configs 形式发布，而不是 chip_parts” - 不适用于此版本。 每代比较矩阵 确认所有九个 <codename>_chip_parts.binarypb blob(v2 到 v7)都连续嵌入 .rodata 的 0xbdf29a0..，由 TpuChipParts::DefaultsForVersion (0x20b1b040) 解析。因此，较旧的通道/子通道/MXU/内存常量是原始来源且可实现的，不是推断的。 HBM/VMEM/SMEM/SFLAG 字节、MXU VectorIsa 和每代频率均直接从线路字节解码。
更正(PGM-1，总结)—每代几何图形不是由
tpu::TpuChipConfig::Create(0x20ae98e0) 编写，作为早期框架的假设。TpuChipConfig::Create通过kChipConfigAliases平面图 (0x2200b8b0) 构建驱动程序端内存/队列布局；车道/子车道几何形状是TpuChipParts/TpuTopology属性。此更正完全归每代比较矩阵 每个嵌入的 blob 中都不存在所有；它在此处记录为 CLOSED per-gen item，因此该寄存器反映了已解决的状态。
正品残片
| 剩余间隙 | 为什么开放 | 关闭者 |
|---|---|---|
chip_config(驱动程序)与 chip_parts(几何)消费者拆分 | 已恢复 — kChipConfigAliases 是由 TpuVersion {2,3,4,5} 键控的静态 4 条目 flat_map<TpuVersionAndVariant, MapView>(所有变体 "default")； v4/v5共享一张子图；别名词汇 default/legacy/megacore/megachip/megachip_tccontrol | per-TpuVersion 分割是静态的，不是设备探测的；只有类型擦除的MapView键→值方向是残留的 |
issue_latency_cycle_count(VectorIsa 字段 4) | 每个嵌入式 blob 中不存在(原始默认值 0) — 真正的每代问题延迟存在于成本模型 Performance 网格中，而不是 chip_parts | chip_parts 填充字段 4 的构建 — 可能永远不存在 |
明白了 —
issue_latency_cycle_count是陷阱。该字段存在于chip_parts模式中，但从未在此构建中填充(对于所有世代，它读取为原始默认值 0)。重新实现者不得**从chip_parts读取 MXU/VPU 问题延迟；实时值通过CycleTable::GetCyclesForThroughput(每代 vtable 插槽+0x10)查询。chip_parts零并不是答案——而是没有答案。
推断链接项目
用途
第四类是通过名称家族协议追踪的 wiki 的边缘——确认类→引擎映射并定位降低通道——但没有对叶编码进行字节转储。这些在其所属页面上的评级为 INFERRED 或 I；它们是真正的前沿，因为结论是值得信赖的，而确切的叶子尚未得到重新验证。
内在→ISel 叶间隙
LLVMTPU内在表 以两种独立的方式恢复所有 1356 个不同的 llvm.tpu.* 内在函数。仍然推断出三个叶级事实：
| 推断链接 | 已知的内容 | 尚未字节确认的内容 |
|---|---|---|
| 834 流操作 | 已解决(负面结果) — 类别→发动机 + 降低位置；编码器 Encode (0x1eb9b4c0) 11 臂 proto-oneof + 4 字节验证字段访问器 | 数字命令是运行时由(form、verb、dtype、memspace)位字段组成 - 没有静态的每叶命令表可供转储 |
| 890 默认构建器操作 | 已恢复 — 从 Op<…> 特征包中读取 1060/1356 的 (#res,#operands) 字节(完整人口普查列表)；流分割 6/8/9、DMA 11/12-iova 修正浮出水面 | 结果 TypeConstraint 是一个负结果：MLIR 层没有每操作寄存器类谓词(所有 OneTypedResult<mlir::Type> + isCompatibleOuterType) - 细化仅存在于下游 LLVM 内在签名中 |
每本征 IntrProperties | 已恢复 — 通过 set = IntrinsicsToAttributesMap[ID−1] >> 9 (@0x416fb30) 的 IntrNoMem/IntrArgMemOnly/IntrWillReturn/… 位；所有 12 个 fn-attr 集均已字节解码、人口普查精确 (1356)、16 叶样本字节验证 | 每叶集，用于未单独转录的 1340 个非采样 ID(确定性半字查找) |
QUIRK — 834 路流操作爆炸是编码 — 没有单个参数化
llvm.tpu.stream操作。这里的前沿不是“找到参数化”(没有)；它是“对 834 个叶子中的每一个叶子进行字节转储匹配器臂”。这是有界的工作，但有 834 个叶子，这就是为什么尽管路径已知，但可关闭性是MEDIUM而不是HIGH。
字节确认计数器示例
并非每个内在→ISel 链接都保持推断。 SparseCore addrspacecast 系列(16 个操作)进行了端到端跟踪并“纠正”了一个常见假设：
修正(INTR-2，总结)— SparseCore
addrspacecast内在函数不低于ISD::ADDRSPACECAST(0xf4) 节点；它们随着 LLVM-IR 内部调用被消费 SC 加载存储 ISel 吸收而存活下来。整个.text外部引用将每个0xf4构造函数调用者放置在通用 LLVM 中，没有放置在 TPU/SC 带中。这是 addrspacecast-isel 拥有的；这里引用它作为推断链接的有效示例，即封闭升级为修正——前沿不仅是“填补空白”，而且是“重新验证和推翻”。
命名开放问题
用途
该带最初是五个 O 分级任务，其深层页面作为存根存在，没有完整的原始结果文件。后来的恢复过程直接从反编译中关闭了 #1092/#1096/#1171 三人组——它们的深层页面现在已满，其中两个在此过程中浮出了 CORRECTION。随后的目标反汇编批次也关闭了 P-3-478..482 SparseCore/DMA 集群(三个恢复字节精确，一个确认非边缘)，因此所有五个命名问题现在都已解决。下表记录了审计跟踪的所有五个。
五项任务(现已全部解决)
| 任务 | 主题 | 所属页面(当前状态) | 什么关闭/关闭它 |
|---|---|---|---|
#1092 | 结构化稀疏时隙编码 (v5+) | 插槽稀疏-v5plus — 已恢复 | 关闭：无专用槽位；稀疏性存在于压缩的 MXU 操作数布局中 |
#1096 | 每代 NOP 规范模板 | nop-规范 — 已恢复 | 关闭：谓词 kNeverExecute=31 填充 + 全 1 操作码 NOP (CORRECTION NOP-1) |
#1171 | TpuVersion 感知标志前缀调度 | 标志前缀调度 — 已恢复 | 已关闭：标志已注册 gen-blind (CORRECTION DISPATCH-1) |
P-3-478..482 | SparseCore / DMA 边缘(集群) | 屏障/成本/计划/isa 页面 — 已恢复 | 已关闭：回调/工厂/溢出字节跟踪； cmem-load/sparsity“边缘”是已确认的非边缘 |
P-3-478..482 集群是一组相关的 SparseCore 和 DMA 边缘，用于馈送完成的页面；现在已经完全解决了。 P-3-478 — InitializeOnScs 查找回调目标 — 字节追踪到 call *0x98 → ExplicitRingRecord/ExplicitAllToAllRingRecord 写入 (ordinal, next_chip, reorder) (张量核势垒)。 P-3-480(LatencyTable::Create(TpuVersion) 的尾部)被恢复为由五个静态初始化 TU 初始值设定项 (循环表系列) 填充的平面序数索引 AnyInvocable 注册表。 P-3-481 — SetLatchIndices 每代溢出握手 — ViperfishTarget::HasMsrOverrunChecks 上的门(唯一返回 TRUE 的代)，因此只有 v5 索引第一个锁存器 (锁存器分配溢出)。 P-3-482 — 假定的 cmem-load → 稀疏 DMA 边缘 — 是一个已确认的 非边缘：v4 cmem-load 发射链不触及 DMA 或稀疏路径，并且稀疏性是不相交的 v5+ SparseCore ISA (插槽-cmem-负载-pf)。
注意 —
#1171现已关闭 —flag-prefix-dispatch已恢复，其OPEN横幅已替换为完整解码(CORRECTION DISPATCH-1：代号前缀标志注册为 gen-blind；活动 gen 仅驱动数据/编解码器选择)。该行保留在此处作为恢复关闭审核条目，与跟踪 zstd 和海象项目保留在下面的墓地中的方式相同。
因更正而关闭(墓地) {#closed-by-correction-the-graveyard}
只会增长的登记册是愿望清单，而不是审计。这些项目在早期分析中是开放的，现在通过更正关闭——后来的证据推翻了最初的主张。它们被保留，而不是删除，因此读者可以看到寄存器反映了当前的事实而不是最初的猜测。
| 已关闭项目 | 原始索赔 | 是什么推翻了它 | 所属更正 |
|---|---|---|---|
| 尾随 zstd blob | ~4.1 MB zstd-dictionary blob 在 0x20f99bef 处附加到 EOF 后面，解码为每个代号的硬件常量 | 偏移量为 ~2.6 MB 内部 .text；字节是 x86-64 mov 立即数；没有字典，没有框架，没有有效负载 | CORRECTION (ZSTD-01) — 尾随-zstd-blob |
| “海象”通行证驱动程序 | 名为“walrus”的 IR/编译器传递管道驱动程序 | 不区分大小写的名称和字符串表搜索返回零次出现；真正的驱动程序是 HLO 通行证注册表，不受任何“海象”符号的控制 | CORRECTION (GLOSS-1) — 术语表 |
| 拆解率(98%) | 98% 的函数带有分解名称(来自 _Z 前缀计数) | _Z 前缀超调：871,370 个 _Z 名称中的约 48,500 个名称未能分解或分解为自身；现场支持率为 822,847 / 884,832 = 93.0% | CORRECTION (METH-D1) — 方法论-深度 |
| 每代几何源 | 车道/子车道几何由 tpu::TpuChipConfig::Create 编写 | TpuChipConfig::Create 仅构建驾驶员侧布局；几何是 MXU VectorIsa 的 TpuTopology 属性 | CORRECTION (PGM-1) — 每代比较矩阵 每个嵌入的 blob 中都不存在 |
QUIRK — 尾随 zstd 闭包是保留寄存器的最有力的论据。最初的声明有文件偏移量、大小、压缩格式和解码目标——它足够具体，可以“声音”恢复。它在每一个重要事实上都是错误的。防御是一次交叉检查：在雕刻之前解决锚点相对于符号图的偏移。这里的每一行都在提醒我们，一个听起来精确的声明，但缺少一个交叉检查，正是重建出错的地方。
交叉引用
- 提取方法，深度 — 拥有 516 + 7,915 故障分类和
METH-D1去角校正；此页面上每个计数的父级 - 证据和置信约定 — 此页面故意偏离的四级行为信心量表(此处信心对可接近性进行分级)
- 尾随 zstd Blob —
ZSTD-01修正；翻转封闭边界项目的工作示例 - 每代比较矩阵 — 每代
chip_parts解码和PGM-1几何源校正 - LLVMTPU 内在表 — 推断的流/构建器/
IntrProperties叶间隙和INTR-2addrspacecast 校正 - 客户端、设备和拓扑 —
PJRT_Client构造路径，其运行时数量取决于硬件 - StreamExecutor → PJRT 适配器 —
TpuClient桥和运行时遥测门 - 旗帜目录，完整 — 设备上哨兵未解析的静态标志默认值
- 插槽稀疏 v5+ · NOP Canonical · Flag-前缀调度 —
#1092/#1096/#1171三重奏，在稍后的过程中恢复，并保留在这里作为恢复关闭 - 嵌入式库图集 — BoringSSL/dnnl 静态链接代码，其手写程序集位于其永久反编译层