Skip to main content

Module decoder

x86_64_assembler

Module decoder 

Source
Expand description

§InstructionDecoder 模块

§设计定位

InstructionDecoder 是机器码到指令的逆向解析引擎，核心设计思路是：在不依赖外部信息的情况下，从字节流中准确还原指令语义。它是整个汇编器的“逆向齿轮“，需要处理 x86 指令集的历史包袱和复杂性。

§架构挑战

§x86 指令解码的独特难题

  1. 变长前缀：1-4 字节前缀，组合规则复杂
  2. 操作数大小歧义：同一 opcode 在不同模式下含义不同
  3. ModR/M 字节爆炸：256 种组合，每种又有子情况
  4. SIB 字节嵌套：基址 + 变址 × 比例 的三元寻址
  5. 位移/立即数混杂：需要精确计算长度，一字节错全盘错

§解码器设计哲学

“不信任任何字节” - 每个解析步骤都要验证：

  • 前缀组合是否合法？
  • opcode 在当前架构下是否有效？
  • ModR/M 模式是否支持？
  • 计算出的指令长度是否合理？

§核心算法流程

解码流程： 字节流经过前缀解析、opcode识别、操作数解码三个阶段，最终生成Instruction对象。

中间状态： 每个阶段产生对应的中间结构：PrefixState记录前缀信息，OpcodeDesc描述操作码，OperandSpec定义操作数规范。

§1. 前缀解析阶段

维护 PrefixState 结构，按优先级处理前缀字节。

前缀状态组件：

  • operand_size: 操作数大小（16/32/64 位）
  • address_size: 地址大小（16/32/64 位）
  • segment_override: 段前缀覆盖
  • repeat_prefix: rep/repne 重复前缀
  • lock: lock 原子操作前缀

关键决策： 前缀顺序不影响语义，但影响编码长度。解码时记录所有前缀，编码时按标准顺序输出。

关键决策： 前缀顺序不影响语义，但影响编码长度。解码时记录所有前缀，编码时按标准顺序输出。

§2. Opcode 识别阶段

两级查找表设计：

  • 主表：256 个主 opcode
  • 扩展表：0x0F 开头的两字节 opcode
  • 架构特定：x86 vs x86_64 的不同解释

歧义处理： 同一 opcode 在不同模式下映射到不同指令，需要结合 PrefixState 和当前 Architecture 综合判断。

§3. 操作数解码阶段

基于 OpcodeDesc.operand_spec 的模式匹配：

伪代码说明 - 操作数规范枚举概念：

enum OperandSpec {
    Reg,        // 隐含寄存器 (如 AL, AX, EAX)
    ModRM,      // ModR/M 字节决定
    Imm,        // 立即数，大小由前缀决定
    Mem,        // 内存操作数，大小由前缀决定
    Rel,        // 相对地址，用于跳转
}

**ModR/M 操作数规范解析

操作数规范定义了解码阶段的操作数表示形式。

操作数类型：

  • 寄存器操作数：直接使用寄存器编码
  • 内存操作数：基址+变址+位移的复杂寻址
  • 立即数操作数：内嵌在指令中的常量值
  • 相对操作数：相对于 RIP/EIP 的跳转目标

关键设计： 解码时保留原始编码信息，编码时尽量复用原有格式。

§架构差异处理

§x86 vs x86_64 的关键区别

特性x86 (32位)x86_64 (64位)解码影响
默认操作数大小32位32位需要 REX.W 才能切换到 64位
默认地址大小32位64位影响 ModR/M 位移计算
可用寄存器8个16个REX 前缀扩展寄存器编码
RIP 相对寻址不支持支持新增寻址模式

§REX 前缀的特殊处理

REX 前缀是 x86_64 的“解码钥匙“：

  • REX.W：切换到 64位操作数大小
  • REX.R：扩展 ModR/M 的 reg 字段
  • REX.X：扩展 SIB 的 index 字段
  • REX.B：扩展 ModR/M 的 r/m 字段或寄存器编号

解码策略： 遇到 REX 前缀立即设置 rex_state，后续所有解析都参考该状态。

§错误处理策略

§解码错误的层级

  1. 格式错误：字节序列根本不符合任何合法指令模式
  2. 架构错误：指令存在但不支持当前架构（如 64位模式下使用 32位段寄存器）
  3. 不完整错误：字节流在指令中间截断
  4. 歧义错误：理论上合法但实践中未定义的行为

§错误恢复机制

当前策略： 遇到错误立即返回，不尝试恢复。 未来考虑： 提供 “最佳猜测” 模式，返回 PartialInstruction 并跳过问题字节继续。

§性能优化思路

§查找表优化

  • 主 opcode 表：256 项数组，O(1) 查找
  • 扩展 opcode 表：哈希表，平衡内存和速度
  • ModR/M 模式表：预计算 256 种情况的解析结果

§零分配策略

当前设计避免堆分配：

  • 返回的 Instruction 在栈上
  • 不使用动态字符串存储
  • 位移/立即数直接解析到结构体中

§缓存友好性

考虑指令边界预测：

  • 记录历史指令长度模式
  • 对跳转目标进行缓存
  • 预取可能的下一条指令

§测试策略

§测试金字塔

  1. 单元测试：每个解析函数独立测试
  2. 集成测试：完整指令往返（编码→解码→编码）
  3. 边界测试：架构切换、前缀组合、极端长度
  4. 回归测试：发现过的 bug 都要加测试防止复发

§测试数据生成

手工构造：覆盖特殊情况和边界条件 随机生成：大量随机字节序列，确保不 panic 已知样本：使用 NASM/YASM 生成的标准测试用例

关键测试： 确保 encode(decode(bytes)) == bytes 对所有合法指令成立。

§扩展指南

§新增指令支持

  1. 更新 opcode 表：在主表或扩展表中添加条目
  2. 定义操作数模式：指定 OperandSpec 序列
  3. 架构标记：注明 x86/x86_64/both 支持
  4. 添加测试用例：特别是架构差异部分

§新架构支持

  1. 架构检测：在 Architecture 枚举中添加新成员
  2. opcode 重映射：处理同一 opcode 的不同语义
  3. 前缀解释：新架构可能有不同的前缀含义
  4. 寄存器扩展：更新寄存器编码解析逻辑

§维护注意事项

§代码组织原则

  • 按功能分组：前缀解析、opcode 识别、操作数解码分开
  • 最小化状态：传递结构体而非多个参数
  • 早期验证：每个解析步骤都检查输入有效性

§常见陷阱

  1. 位移符号扩展：8位位移在解码时要正确符号扩展
  2. 立即数字节序：x86 是小端序，多字节立即数要注意
  3. RIP 相对寻址：计算的是下一条指令的地址
  4. 段覆盖前缀：影响内存操作数的段选择，但不改变指令语义
  5. 锁前缀：只允许特定的原子操作使用

§调试技巧

  • hexdump 对照：打印原始字节和解码结果对比
  • 分阶段验证：前缀→opcode→操作数，逐步确认
  • 参考实现：对照 Intel 手册和现有汇编器行为
  • 边界测试：单字节指令、最大长度指令都要覆盖

解码器是汇编器中最复杂的部分，因为它要处理几十年积累下来的指令集复杂性。每次修改都要极其小心，一个位的错误可能导致完全不同的指令解释。

Structs§

InstructionDecoder
指令解码器，用于将字节码解码为指令