两个内联汇编调用与一个内联汇编调用中的内存破坏？答案

【问题标题】：Clobbered memory in two inline assembly calls vs in one inline assembly call?两个内联汇编调用与一个内联汇编调用中的内存破坏？
【发布时间】：2018-07-09 15:09:47
【问题描述】：

这个问题遵循one，考虑到符合GCC 的编译器和x86-64 架构。

我想知道下面的option 1、option 2 和option 3 之间是否有任何区别。结果在所有情况下都是相同的，还是会有所不同。如果是这样，有什么区别？

// Option 1
asm volatile(:::"memory");
asm volatile("CPUID":"=a"(eax),"=b"(ebx),"=c"(ecx),"=d"(edx):"0"(level):);

和

// Option 2
asm volatile("CPUID":"=a"(eax),"=b"(ebx),"=c"(ecx),"=d"(edx):"0"(level):);
asm volatile(:::"memory");

和

// Option 3
asm volatile("CPUID":"=a"(eax),"=b"(ebx),"=c"(ecx),"=d"(edx):"0"(level):"memory");

【问题讨论】：

2&3 应该相同。 1 将强制从内存中重新加载level，如果它恰好在那里。
@Jester: 选项 2 将让 CPUID 本身重新排序与不相关的非volatile 加载/存储。这很可能不是你想要的。
@Jester：实际上只有在它的地址已经转义函数时才会重新加载，或者类似的东西。如果它作为堆栈参数在内存中，或者由于寄存器压力而导致正常的本地溢出，它不会强制重新加载。

标签： c++ gcc assembly inline-assembly cpuid

【解决方案1】：

选项 1 和 2 将让 CPUID 本身使用不相关的非volatile 加载/存储（在一个方向或另一个方向）重新排序。这很可能不是你想要的。

您可以在 CPUID 的两边设置内存屏障，但最好让 CPUID 本身成为内存屏障。

正如 Jester 所指出的，选项 1 将强制从内存中重新加载 level，如果它曾经将其地址传递到函数之外，或者如果它已经是一个全局或 @987654325 @。

(或者任何决定C变量是否可以被使用"memory" clobber的asm修改读取或写入的确切标准。我认为它与优化器用来决定变量是否可以是基本相同的在对不透明函数的非内联函数调用中保存在寄存器中，因此没有将地址传递到任何地方并且不是 asm 语句的输入的纯局部变量仍然可以存在于寄存器中。

例如（Godbolt compiler explorer）：

void foo(int level){
    int eax, ebx, ecx, edx;
    asm volatile("":::"memory");
    asm volatile("CPUID"
        :  "=a"(eax),"=b"(ebx),"=c"(ecx),"=d"(edx)
        :  "0"(level)
        :
    );
}

# x86-64 gcc7.3  -O3 -fverbose-asm

    pushq   %rbx  #           # rbx is call-preserved, but we clobber it.
    movl    %edi, %eax      # level, eax
    CPUID
    popq    %rbx    #
    ret

请注意缺少函数 arg 的溢出/重新加载。

通常我会使用 Intel 语法，但对于内联汇编，最好始终使用 AT&T，除非您完全讨厌 AT&T 语法或不知道它。

即使它在内存中启动（i386 System V 调用约定，带有堆栈参数），编译器仍然决定没有其他任何东西（包括带有内存破坏器的 asm 语句）可以引用它。但是我们如何区分延迟加载呢？修改barrier之前的函数arg，之后使用：

void modify_level(int level){
    level += 1;                  // modify level before the barrier
    int eax, ebx, ecx, edx;
    asm volatile("#mem barrier here":::"memory");
    asm volatile("CPUID"         // then read it after
    :  "=a"(eax),"=b"(ebx),"=c"(ecx),"=d"(edx)
    :  "0"(level):);
}

gcc -m32 -O3 -fverbose-asm 的 asm 输出为：

modify_level(int):
    pushl   %ebx  #
    #mem barrier here
    movl    8(%esp), %eax   # level, tmp97
    addl    $1, %eax        #, level
    CPUID
    popl    %ebx    #
    ret

请注意，编译器让level++ 跨内存屏障重新排序，因为它是一个局部变量。

Godbolt 过滤手写 asm cmets 以及编译器生成的 asm 仅注释行。我禁用了评论过滤器并找到了内存屏障。您可能需要删除 -fverbose-asm 以减少噪音。或者对 mem 屏障使用非注释字符串：如果您只是查看编译器的 asm 输出，则不必组装它。（除非您使用的是内置汇编器的 clang）。

顺便说一句，您的问题的原始版本没有编译：您将空字符串作为 asm 模板遗漏了。 asm(:::"memory")。 output、input 和 clobber 部分可以为空，但 asm 指令字符串不是可选的。

有趣的是，你可以将 asm cmets 放在字符串中：

asm volatile("# memory barrier here":::"memory");

gcc 在写入 asm 输出时会填写字符串模板中的任何 %whatever 内容，因此您甚至可以执行 "CPUID # %%0 was in %0" 之类的操作，并查看 gcc 为您的“虚拟”args 选择了什么，这些参数在 asm 模板中未提及. （当你给 asm 语句一个指针时，这对于虚拟内存输入/输出操作数告诉编译器你读/写哪个内存而不是使用 "memory" clobber 更有趣。）

【讨论】：

“通常我会使用 Intel 语法” - 除非您正在为库创建标头，否则请考虑使用 dialects。想法是，作为标头，您无法知道包含在其中的文件是使用 -masm=intel 还是 att 构建的。