# PPT 补充 · #10 重复求解量化 + 关键约束量级 + ustar 编译形态

> 均为实验机实测（`ubuntu@cuda-ke`，AFL++ 4.40c，clang/LLVM 18）。

---

## ① #10 重复求解占比拆分（唯一硬缺口，已实测）

在 hybrid worker 端加了 opt-in 计数（`SYMCC_WORKER_PROFILE=1`），统计漏斗
**生成 → worker 上报（过 worker 自身 dedup）→ master 接受（过全局 dedup）**。
lava-base64 / np=12，3 次独立运行，结果高度一致：

| 阶段 | 占生成 | 说明 |
|---|---|---|
| generated（SymCC 输出总数） | 100% | — |
| reported（worker 判新上报） | ~40% | 过了 worker 自身 dedup |
| **accepted（master 全局判新）** | **~17–20%** | 真正纳入语料的 |

**冗余（≈80% 的输出）按发生位置拆分（3 次运行）:**

| 位置 | 占生成 | **占冗余** |
|---|---|---|
| **worker-内**（worker 自身 dedup 丢的，SymCC 单次 concolic 自复） | ~58–63% | **~70–79%** |
| **worker-间 / bitmap 新鲜度间隙**（worker 判新、master 全局已有） | ~17–25% | **~21–30%** |

→ **量化坐实"worker-内是大头"：约 3 : 1（worker-内 ≈ ¾ 冗余，worker-间 ≈ ¼）。**
worker-间那部分**就是** bitmap 新鲜度间隙（worker 的位图快照相对 master 当前的滞后）。

**"乐观求解不可行 vs 新鲜度间隙"的更细根因——诚实说明:**
这一层我**没能可靠量化**。要区分"输出没打到任何全局新边(乐观求解不可行)"与"打到新边但被抢先
(新鲜度)"，需要在【每个输出生成时刻】拿到全局覆盖快照。但在这些短跑里，**每个 worker 只跑完 1 个
长 item（一次 concolic 生成上百输出、其 showmap 后处理吃满窗口），而它先于 master 写出 .shared_bitmap
完成**，故 worker 全程未获全局位图播种（实测 snap_none=100%）。因此：
- **可测下界**：worker-间（≈¼ 冗余）就是新鲜度间隙。
- **乐观求解不可行**：混在 worker-内自复（≈¾）里，无法在 Python/worker 层与普通自复分开——精确隔离
  需在 SymCC C++ 运行时打点（判定乐观解是否真的走到目标分支）。deck 里建议如实写：
  **"新鲜度间隙 ≈¼；其余 ≈¾ 为 worker 内单次 concolic 的输出自复(含乐观求解不可行，未单独隔离)"**。

数据文件：`06_redundancy_split.csv`。实现：`util/mpi_fuzzing_helper.py`（提交 5df64e1）。

---

## ② magic 类目标的关键难约束量级（confirm 用）

不建议用 objdump 数立即数（噪声大：把地址/偏移都算进去，`who` 会数出上千，无意义）。用两个可信口径：

- **base64（LAVA-M）**：一次 concolic 实测 SymCC 求解出 **10 条不同约束**（`.hints` 的 offset:old:new）；
  文献 LAVA-M base64 共注入 **44 个 bug**（每个由一个 4 字节 magic 比较守护）。
  → **关键难约束是"十几~几十条"量级，不是成百上千。**
- **libarchive**：格式识别是少数几种容器 magic（tar `ustar`、zip `PK`、cpio…）在入口分流，之后按格式解析；
  真正"卡住覆盖前进"的 magic 关卡也是**个位到低几十**量级。

→ 支持"号称路径爆炸却撑不起百进程"：**有效独立难约束就几十条量级，且多为嵌套/顺序依赖**（解开一个
才够到下一个），所以并行度超过"几十"后收益递减。答辩口头给这个量级即可。

---

## ③（遗留）ustar 实际编译形态：内联，非 laf 拆分

对 `libarchive-afl/archive_fuzzer` 反汇编 `header_ustar`（294 条指令）：

- **零** `memcmp/strncmp/bcmp/strcmp` 调用 → magic 比较是**编译器内联**的（没走库函数）。
- 二进制是 **PCGUARD 插桩（afl-clang-fast 默认），不是 laf-intel** → 所以 **ustar 魔数【不是】laf 逐字节拆分**。
- 形态：内联的字节/指针级比较序列（非单条整宽 cmp，也非 memcmp call）。

→ 结论：**ustar 是编译器内联比较，非 laf 拆分**。对 cmplog/RedQueen 友好（能看到比较操作数、可穿透魔数）；
这也印证了此前"cmplog 主导、不必再加 laf-intel"的取舍。