x86-64 SysV ABI 中的参数和返回值寄存器的高位是否允许垃圾？

Question

x86-64 SysV ABI 指定函数参数如何在寄存器中传递（rdi 中的第一个参数，然后是rsi 等等），以及整数返回值如何传回（@ 987654331@ 然后rdx 用于非常大的值）。

但是，当传递小于 64 位的类型时，我找不到参数或返回值寄存器的高位应该是什么。

例如，对于以下函数：

void foo(unsigned x, unsigned y);

...x 将在 rdi 和 y 中传递给 rsi，但它们只有 32 位。 rdi 和 rsi 的高 32 位是否需要为零？直觉上，我会假设是的，但是所有 gcc、clang 和 icc 的 code generated 在开始时都有特定的 mov 指令将高位清零，所以编译器似乎假设不是这样。

同样，如果返回值小于 64 位，编译器似乎假设返回值rax 的高位可能有垃圾位。例如下面代码中的循环：

unsigned gives32();
unsigned short gives16();

long sum32_64() {
  long total = 0;
  for (int i=1000; i--; ) {
    total += gives32();
  }
  return total;
}

long sum16_64() {
  long total = 0;
  for (int i=1000; i--; ) {
    total += gives16();
  }
  return total;
}

...compile 到 clang 中的以下内容（其他编译器类似）：

sum32_64():
...
.LBB0_1:                               
    call    gives32()
    mov     eax, eax
    add     rbx, rax
    inc     ebp
    jne     .LBB0_1


sum16_64():
...
.LBB1_1:
    call    gives16()
    movzx   eax, ax
    add     rbx, rax
    inc     ebp
    jne     .LBB1_1

注意调用返回 32 位后的 mov eax, eax 和 16 位调用后的 movzx eax, ax - 两者都分别具有将前 32 位或 48 位清零的效果。所以这种行为是有代价的——处理 64 位返回值的相同循环省略了这条指令。

我已经非常仔细地阅读了x86-64 System V ABI document，但我找不到标准中是否记录了这种行为。

这样的决定有什么好处？在我看来有明确的成本：

参数成本

在处理参数值时，被调用者的实现会产生成本。并在处理参数时的函数中。当然，这个成本通常为零，因为该函数可以有效地忽略高位，或者归零是免费的，因为可以使用 32 位操作数大小的指令来隐式地将高位归零。

但是，在函数接受 32 位参数并进行一些可以从 64 位数学中受益的数学运算的情况下，成本通常是非常实际的。以this function 为例：

uint32_t average(uint32_t a, uint32_t b) {
  return ((uint64_t)a + b) >> 2;
}

直接使用 64 位数学计算一个函数，否则必须仔细处理溢出问题（以这种方式转换许多 32 位函数的能力是 64 位架构的一个经常被忽视的好处）。这编译为：

average(unsigned int, unsigned int):
        mov     edi, edi
        mov     eax, esi
        add     rax, rdi
        shr     rax, 2
        ret  

仅需要 4 条指令中的 2 条（忽略 ret）将高位清零。这在实践中使用 mov 消除可能很便宜，但仍然需要付出很大的代价。

另一方面，如果 ABI 指定高位为零，我真的看不到调用者的类似相应成本。因为rdi 和rsi 和其他参数传递寄存器是scratch（即可以被调用者覆盖），你只有几个场景（我们看rdi，但是替换它与您选择的参数 reg 一起使用）：

1. rdi 中传递给函数的值在调用后代码中已失效（不需要）。在这种情况下，最后分配给rdi 的任何指令只需分配给edi。这不仅是免费的，如果您避免使用 REX 前缀，它通常会小一个字节。

2. rdi 中传递给函数的值 需要在函数之后。在这种情况下，由于rdi 是调用者保存的，调用者无论如何都需要对被调用者保存的寄存器执行mov 的值。您通常可以组织它，以便值 starts 在被调用方保存的寄存器中（比如rbx），然后像mov edi, ebx 一样移动到edi，所以它没有任何成本。

我看不到很多归零会花费调用者很多钱的情况。一些例子是如果在分配rdi 的最后一条指令中需要 64 位数学。不过，这似乎很少见。

回报价值成本

这里的决定似乎更加中立。让被调用者清除垃圾有一个明确的代码（您有时会看到执行此操作的mov eax, eax 指令），但如果允许垃圾，则成本会转移到被调用者身上。总体而言，调用者似乎更有可能免费清除垃圾，因此允许垃圾似乎总体上不会损害性能。

我想这种行为的一个有趣用例是具有不同大小的函数可以共享相同的实现。例如，以下所有函数：

short sums(short x, short y) {
  return x + y;
}

int sumi(int x, int y) {
  return x + y;
}

long suml(long x, long y) {
  return x + y;
}

实际上可以共享相同的实现¹：

sum:
        lea     rax, [rdi+rsi]
        ret

---

¹对于被占用地址的函数，这种折叠是否真的允许非常多open to debate。

Answer 1

您似乎有两个问题：

1. 返回值的高位是否需要在返回前清零？ （在调用之前是否需要将高位参数归零？）
2. 与此决定相关的成本/收益是什么？

第一个问题的答案是不，有可能在高位是垃圾，Peter Cordes 已经写了一个very nice answer 关于这个主题。

至于第二个问题，我怀疑不定义高位总体上会更好地提高性能。一方面，在使用 32 位操作时，预先零扩展值不会产生额外成本。但另一方面，事先将高位归零并不总是必要的。如果您允许高位出现垃圾，那么您可以将其留给接收值的代码，以便仅在实际需要时执行零扩展（或符号扩展）。

但我想强调另一个考虑因素：安全

信息泄露

当结果的高位未清除时，它们可能会保留其他信息的片段，例如堆栈/堆中的函数指针或地址。如果曾经存在一种机制来执行更高权限的函数并在之后检索rax（或eax）的完整值，那么这可能会导致信息泄漏。例如，系统调用可能会从内核泄漏指向用户空间的指针，从而导致内核ASLR 失败。或者IPC 机制可能会泄漏有关另一个进程的地址空间的信息，这可能有助于开发sandbox 突破。

当然，有人可能会争辩说，防止信息泄露不是 ABI 的责任；由程序员正确实现他们的代码。虽然我同意，但强制编译器将高位归零仍然可以消除这种特殊形式的信息泄漏。

你不应该相信你的意见

另一方面，更重要的是，编译器不应盲目相信任何接收到的值的高位都被清零，否则函数可能无法按预期运行，这也可能导致可利用的条件。例如，考虑以下情况：

unsigned char buf[256];
...
__fastcall void write_index(unsigned char index, unsigned char value) {
    buf[index] = value;
}

如果允许我们假设index 的高位被清零，那么我们可以将上面的代码编译为：

write_index:  ;; sil = index, dil = value
      ; movzx esi, sil       ; skipped based on assumptions
    mov [buf + rsi], dil
    ret

但如果我们可以从我们自己的代码中调用此函数，我们可以提供一个超出[0,255] 范围的值rsi 并写入超出缓冲区边界的内存。

当然，编译器实际上不会生成这样的代码，因为如上所述，被调用者有责任对其参数进行零或符号扩展，而不是调用者。我认为，这是一个非常实际的理由，让接收值的代码始终假定高位存在垃圾并显式删除它。

（对于英特尔 IvyBridge 和更高版本（mov-elimination），编译器希望零扩展到 不同 寄存器，以至少避免延迟，如果不是前端吞吐量成本， movzx 指令。）