首页 > 解决方案 > 内联汇编在没有优化的情况下无法编译

问题描述

我在 32 位 Linux 进程中需要 futex 系统调用,但无法使用该syscall功能(标头不可用)。这仍然可以通过使用内联汇编来完成,如下所示:

#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;
}

正如预期的那样编译。

但是,由于我们没有指定可以读取和/或写入的内存位置,它可能会导致一些偷偷摸摸的错误。因此,我们可以使用虚拟内存输入和输出(如何指示可以使用内联 ASM 参数*指向*的内存?

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。当用 编译时clang -fomit-frame-pointer -m32,它会以 . 失败inline assembly requires more registers than available。不过,我不明白为什么。

但是,当使用-O1 -m32(或除 之外的任何级别-O0)编译时,它编译得很好。

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

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

还有其他解决方案吗?

标签: clinuxx86inline-assemblycpu-registers

解决方案


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

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

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

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


推荐阅读