內聯匯編在沒有優化的情況下無法編譯

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。