内联汇编在没有优化的情况下无法编译

Question

我需要 32 位 Linux 进程中的 futex 系统调用，但不能使用syscall function（标头不可用）。 这仍然可以通过使用内联汇编来完成，如下所示：

#include <time.h>

#define SYS_futex 0xf0

// We need -fomit-frame-pointer in order to set EBP
__attribute__((optimize("-fomit-frame-pointer")))
int futex(int* uaddr, int futex_op, int val, const struct timespec* timeout, int* uaddr2, int val3)
{
    register int ebp asm ("ebp") = val3;
    int result;
    asm volatile("int $0x80"
                 : "=a"(result)
                 : "a"(SYS_futex), "b"(uaddr), "c"(futex_op), "d"(val), "S"(timeout), "D"(uaddr2), "r"(ebp)
                // : "memory"  // would make this safe, but could cause some unnecessary spills.  THIS VERSION IS UNSAFE ON PURPOSE, DO NOT USE.
          );
        
    if (result < 0)
    {
        // Error handling
        return -1;
    }
    return result;
}

正如预期的那样编译。

但是，由于我们没有指定可以读取和/或写入的 memory 位置，因此可能会导致一些偷偷摸摸的错误。 因此，相反，我们可以使用虚拟 memory 输入和输出（ 如何指示可以使用内联 ASM 参数指向的 memory *pointed*？ ）

asm volatile("int $0x80"
             : "=a"(result), "+m"(uaddr2)
             : "a"(SYS_futex), "b"(uaddr), "c"(futex_op), "d"(val), "S"(timeout), "D"(uaddr2), "r"(ebp), "m"(*uaddr), "m"(*timeout));

当使用gcc -m32编译时，它会因'asm' operand has impossible constraints possible constraint 失败。 当使用clang -fomit-frame-pointer -m32编译时，它会因inline assembly requires more registers than available而失败。 不过，我不明白为什么。

但是，当使用-O1 -m32 （或-O0以外的任何级别）编译时，它编译得很好。

我看到两个明显的解决方案：

1. 改用"memory" clobber，这可能过于严格，阻止编译器将不相关的变量保存在寄存器中
2. 使用__attribute__((optimize("-O3"))) ，我想避免

还有其他解决方案吗？

Answer 1

编译器不知道您实际上并没有使用*uaddr和*timeout操作数，因此如果您要使用它们，它仍然必须决定%9和%10应该扩展到什么。 这些对象的地址作为参数传递，因此无法生成直接的 memory 引用； 它必须是间接的，这意味着需要分配寄存器来存储这些地址； 例如，编译器可以尝试将指针uaddr加载到ecx中，然后将%9扩展为(%ecx) 。 不幸的是，您已经为其他操作数声明了所有机器的寄存器，因此没有可用于此目的的寄存器。

启用优化后，编译器足够聪明，可以确定指针uaddr已在ebx中可用，因此它可以将%9扩展为(%ebx) ，同样将%10扩展为(%esi) 。 然后它不需要任何额外的寄存器，一切都很好。

如果您确实在 inline asm 中提到%9和%10 ，您会看到这种情况发生，如本例所示。 随着优化，它就像我说的那样。 如您所知，如果没有优化，它无法编译，但是如果我们删除其他几个操作数以释放一些寄存器（此处为ecx和edx ），我们会看到它现在正在扩展%7, %8 （它们被重新编号）到(%edx), (%ecx) ，并相应地提前加载这些寄存器。 它不知道这是多余的，因为edx和ebx都包含相同的值。

除了您已有的想法外，我认为没有任何好的方法可以避免这种情况：启用优化或使用“内存”破坏器。 我怀疑“内存”破坏器实际上会影响如此短的 function 中生成的代码，无论如何，如果您在没有优化的情况下进行编译，那么您已经放弃了任何高效代码的希望。 或者，只需在汇编中编写整个 function。