FuelLabs/sway编译器中的寄存器保存漏洞分析与修复

在FuelLabs/sway编译器项目中，我们发现了一个关键的代码生成问题，涉及函数调用时的寄存器保存机制。这个问题可能导致程序执行时寄存器值被意外修改，进而引发不可预测的行为。

问题背景

在编译器设计中，函数调用时需要保存调用者(caller)的寄存器状态，确保被调用函数(callee)执行完毕后能恢复原有寄存器值。现代编译器通常会进行优化，只保存那些会被callee修改的寄存器，而不是全部寄存器，这被称为"调用约定"(calling convention)。

FuelLabs/sway编译器在实现这一机制时存在不足，导致某些情况下寄存器保存不完整，可能破坏调用者的寄存器状态。

技术细节分析

问题的核心在于编译器错误地假设每条指令最多只会修改一个寄存器。当遇到修改多个寄存器的指令时，编译器只会记录第一个被修改的寄存器，而忽略其他寄存器。

具体来看，在emit_pusha_popa函数中，寄存器收集逻辑如下：

let reg = match &op.opcode {
    // ...其他匹配分支...
    Either::Left(alloc_op) => alloc_op.def_registers().into_iter().next(),
    Either::Right(ctrl_op) => ctrl_op.def_registers().into_iter().next(),
};

这里使用了.next()方法只获取第一个被修改的寄存器，而忽略了指令可能修改的其他寄存器。正确的做法应该是遍历所有被修改的寄存器。

问题影响

这个问题会导致以下情况：

1. 调用者寄存器可能在函数调用后被意外修改
2. 程序可能使用错误的寄存器值继续执行
3. 计算结果可能不正确
4. 在极端情况下可能导致严重后果

复现案例

考虑以下Sway智能合约代码：

#[storage(read)]
fn setup() -> () {
    let a: u64 = 1;
    let b: u64 = 1;
    let c: u64 = 1;
    store_read();
    let r = asm(r, a: a, b: b, c: c, d: store_read()) {
        movi r i0;  
        add r a b;  // r = 2
        add r r c;  // 预期r=3，但c可能被修改
        add r r d;  // 最终结果错误
        r
    };
    assert(r == 3);
    ()
}

在这个例子中，store_read()函数内部修改了寄存器$r3(存储变量c的值)，但由于寄存器保存不完整，导致setup()函数中的c值被意外修改，最终断言失败。

解决方案

修复这个问题需要修改寄存器收集逻辑，确保记录指令修改的所有寄存器。具体应该：

1. 移除.next()调用
2. 遍历所有def_registers()
3. 将所有被修改的寄存器加入保存集合

修改后的核心逻辑应该类似于：

let regs = match &op.opcode {
    // ...其他匹配分支...
    Either::Left(alloc_op) => alloc_op.def_registers(),
    Either::Right(ctrl_op) => ctrl_op.def_registers(),
};

for reg in regs {
    for active_label in active_sets.clone() {
        reg_sets
            .entry(active_label)
            .and_modify(|regs| {
                regs.insert(reg.clone());
            })
            .or_insert_with(|| {
                BTreeSet::from_iter(std::iter::once(reg).cloned())
            });
    }
}

总结

这个问题展示了编译器开发中寄存器管理的重要性。在实现调用约定优化时，必须确保不会遗漏任何可能被修改的寄存器。FuelLabs/sway项目通过修复这个问题，提高了编译器的可靠性和生成代码的正确性。

对于智能合约开发者而言，这类底层编译器问题尤其需要注意，因为它们可能导致合约行为与预期不符。因此，在智能合约开发中，除了关注业务逻辑外，也需要了解底层编译器的特性和限制。