可变/修改的返回地址答案

【问题标题】：Volatile/modified return address可变/修改的返回地址
【发布时间】：2017-04-04 19:42:34
【问题描述】：

考虑一个 C 函数（带有外部链接），如下所示：

void f(void **p)
{
  /* do something with *p */
}

现在假设f 的调用方式使得p 指向堆栈上f 的返回地址，如以下代码所示（假设System V AMD64 ABI）：

leaq -8(%rsp), %rdi
callq f

可能发生的情况是f的代码通过给*p赋值来修改栈上的返回地址。因此，编译器必须将堆栈上的返回地址视为易失性值。我如何告诉编译器，在我的例子中是 gcc，返回地址是 volatile 的？

否则，编译器至少在原则上可以为f生成以下代码：

pushq %rbp
movq 8(%rsp), %r10
pushq %r10
## do something with (%rdi)
popq %r10
popq %rbp
addq 8,%rsp
jmpq *%r10

诚然，编译器不太可能生成这样的代码，但如果没有任何进一步的函数属性，似乎也不会被禁止。并且这段代码不会注意到堆栈上的返回地址是否在函数中间被修改，因为原始返回地址已经在函数开始时被检索到。

P.S.：正如 Peter Cordes 所建议的，我应该更好地解释我的问题的目的：它是关于使用移动垃圾收集器动态生成机器代码的垃圾收集：函数 f 代表垃圾收集器。 f 的被调用者可能是一个函数，其代码在 f 运行时被移动，所以我想出了让 f 知道返回地址的想法，以便 f 可以根据是否修改它返回地址指向的内存区域是否已移动。

【问题讨论】：

所有这些都是未定义的行为
在真正编译的实际代码中遇到真正问题时回来。对依赖于实现的东西的理论讨论是乏味的。
@Marc：您需要使用最小的汇编函数来包装函数，该函数调用f() 并使用堆栈上的返回地址。如果f()的目的只是为了改变返回地址，你应该完全用汇编写。
你应该把为 JITed 代码编写 GC 的解释放入问题中。以它为动力更有意义！
@Marc：是的，包装器越来越有意义。您可以让包装函数（当然是在不移动的代码部分中，没有被 JIT 处理）提供一个额外的指针，指向包装函数堆栈帧中的返回地址。 SYSV AMD64 ABI 很简单，如果你说f() 有5 个参数，你可以设置第六个（%r9）指向堆栈上的返回地址；作为一个纯汇编函数，您甚至不需要适当的堆栈框架，并且包装器将是最小的。运行时成本只是额外的调用。

标签： c gcc x86-64 volatile jit

【解决方案1】：

在 AMD64/x86-64 上使用 SysV ABI（Linux、FreeBSD、Solaris、Mac OS X / macOS），您只需要一个简单的组装函数来包裹实际的垃圾收集器功能。

下面的f.s定义了void f(void *)，调用了真正的GC，real_f(void *, void **)，添加的第二个参数指向返回地址。

    .file       "f.s"
    .text

    .p2align    4,,15
    .globl      f
    .type       f, @function

f:
    movq        %rsp, %rsi
    call        real_f
    ret

    .size       f, .-f

如果real_f() 已经有两个其他参数，请使用%rdx（第三个）而不是%rsi。如果三到五个，请分别使用%rcx、%r8 或%r9。 AMD64/x86-64 上的 SysV ABI 最多仅支持寄存器中的六个非浮点参数。

让我们用一个小的example.c来测试一下：

#include <stdlib.h>
#include <stdio.h>

extern void f(void *);

void real_f(void *arg, void **retval)
{
    printf("real_f(): Returning to %p instead of %p.\n", arg, *retval);
    *retval = arg;
}

int main(void)
{
    printf("Function and label addresses:\n");
    printf("%p f()\n", f);
    printf("%p real_f()\n", real_f);
    printf("%p one_call:\n", &&one_call);
    printf("%p one_fail:\n", &&one_fail);
    printf("%p one_skip:\n", &&one_skip);
    printf("\n");

    printf("f(one_skip):\n");
    fflush(stdout);

one_call:
    f(&&one_skip);

one_fail:
    printf("At one_fail.\n");
    fflush(stdout);

one_skip:
    printf("At one_skip.\n");
    fflush(stdout);

    return EXIT_SUCCESS;
}

请注意，上述内容依赖于 GCC 行为（&& 提供标签地址）以及 AMD64/x86-64 架构上的 GCC 行为（对象和函数指针可互换）以及 C 编译器不对main() 中的代码进行任何允许他们进行的无数优化。

(real_f() 是否优化无关紧要；只是我懒得在main() 中找到更好的示例。例如，在调用@ 的可执行数据段中创建一个小函数987654337@，real_f() 移动该数据段，并相应地调整返回地址。这将符合 OP 的场景，并且几乎是我能想到的这种操作的唯一实际用例。相反，我只是破解了一个粗略的例子可能适用于其他人，也可能不适用。）

另外，我们可能希望将f() 声明为具有两个参数（它们将在%rdi 和%rsi 中传递），第二个无关紧要，以确保编译器不会期望%rsi保持不变。（如果我没记错的话，SysV ABI 可以让我们破坏它，但我可能记错了。）

在这台特定的机器上，编译上面的代码

gcc -Wall -O0 f.s example.c -o example

运行它

./example

生产

Function and label addresses:
0x400650 f()
0x400659 real_f()
0x400729 one_call:
0x400733 one_fail:
0x40074c one_skip:

f(one_skip):
real_f(): Returning to 0x40074c instead of 0x400733.
At one_skip.

请注意，如果您告诉 GCC 优化代码（例如，-O2），它将对 main() 中的代码做出假设，这是 C 标准完全允许的，但这可能导致所有这三个标签具有完全相同的地址。这发生在我的特定机器和 GCC-5.4.0 上，当然会导致无限循环。它根本没有反映f() 或real_f() 的实现，只是我在main() 中的示例很差。我很懒。

【讨论】：