Question

IT工程专业的学生。我们被要求玩上下文切换，一个特定的任务让我们实现了一个相当粗糙的try / throw系统。这是我们一直在写的代码：

struct ctx_s {
  int esp;
  int ebp;
};

struct ctx_s * pctx;

typedef int (func_t)(int); /* a function that returns an int from an int */

int try(func_t *f, int arg)
{
  /* saving context by storing values of %esp and %ebp */      
    asm ("movl %%esp, %0"
    : "=r"((*pctx).esp) 
    :
    );

    asm ("movl %%ebp, %0"
    : "=r"((*pctx).ebp) 
    :
    );

    /* calling the function sent to try(), returning whatever it returns */
    return f(arg);
}

int throw(int r)
{
    printf("MAGIC PRINT\n");

    static int my_return = 0;
    /* ^ to avoid "an element from initialisation is not a constant" */
    my_return = r;
    /* restituting context saved in try() */
    asm ("movl %0, %%esp"
    : 
    : "r"((*pctx).esp) 
    );

    asm ("movl %0, %%ebp"
    : 
    : "r"((*pctx).ebp) 
    );

    /* this return will go back to main() since we've restored try()'s context
     so the return address is whatever called try... */
    /* my_return is static (=> stored in the heap) so it's not been corrupted,
     unlike r which is now the second parameter received from try()'s context, 
     and who knows what that might be */
    return my_return;
}

pctx是一个指向一个包含两个int的简单结构的全局指针，f是一个函数，它调用throw（）发送一些返回代码#define'd到42，而main（）实际上是分配pctx，结果= try（f ，0）并打印结果。我们预计结果为42。

现在，您可能已经在throw（）中发现了MAGIC PRINT。这是因为原因不完全清楚;基本上，大多数（不是所有）学生都是在seg（）内部进行segfaulting;在这个函数中调用printf（）使程序看起来正常工作，老师认为任何系统调用都可以正常工作。

由于我没有真正得到他们的解释，我尝试比较两个版本（有和没有printf（））用gcc -S生成的汇编代码，但我无法做多少。在throw（）的左大括号（第33行）设置一个断点并用gdb反汇编给了我这个：

没有printf（）：

Breakpoint 1, throw (r=42) at main4.c:38
(gdb) disass
Dump of assembler code for function throw:
0x0804845a <throw+0>:   push   %ebp
0x0804845b <throw+1>:   mov    %esp,%ebp
0x0804845d <throw+3>:   mov    0x8(%ebp),%eax
0x08048460 <throw+6>:   mov    %eax,0x8049720
0x08048465 <throw+11>:  mov    0x8049724,%eax
0x0804846a <throw+16>:  mov    (%eax),%eax
0x0804846c <throw+18>:  mov    %eax,%esp
0x0804846e <throw+20>:  mov    0x8049724,%eax
0x08048473 <throw+25>:  mov    0x4(%eax),%eax
0x08048476 <throw+28>:  mov    %eax,%ebp
0x08048478 <throw+30>:  mov    0x8049720,%eax
0x0804847d <throw+35>:  pop    %ebp
0x0804847e <throw+36>:  ret    
End of assembler dump.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xb7e846c0 in ?? ()

使用printf（）：

Breakpoint 1, throw (r=42) at main4.c:34
(gdb) disassemble 
Dump of assembler code for function throw:
0x0804845a <throw+0>:   push   %ebp
0x0804845b <throw+1>:   mov    %esp,%ebp
0x0804845d <throw+3>:   sub    $0x18,%esp
0x08048460 <throw+6>:   movl   $0x80485f0,(%esp)
0x08048467 <throw+13>:  call   0x8048364 <puts@plt>
0x0804846c <throw+18>:  mov    0x8(%ebp),%eax
0x0804846f <throw+21>:  mov    %eax,0x804973c
0x08048474 <throw+26>:  mov    0x8049740,%eax
0x08048479 <throw+31>:  mov    (%eax),%eax
0x0804847b <throw+33>:  mov    %eax,%esp
0x0804847d <throw+35>:  mov    0x8049740,%eax
0x08048482 <throw+40>:  mov    0x4(%eax),%eax
0x08048485 <throw+43>:  mov    %eax,%ebp
0x08048487 <throw+45>:  mov    0x804973c,%eax
0x0804848c <throw+50>:  leave  
0x0804848d <throw+51>:  ret    
End of assembler dump.
(gdb) c
Continuing.
MAGIC PRINT
result = 42

Program exited normally.

我真的不知道该怎么做。显然情况正在发生不同，但我发现很难理解在任何一种情况下发生了什么...... 所以我的问题基本上是：如何调用printf make throw而不是segfault？

Answer 1

您正在“恢复”ESP到另一个函数中保存的值。这里可能不是一个有用的值。

与“神奇”代码的不同之处在于它使编译器在throw函数中保存并恢复堆栈帧。

最后的leave指令相当于

mov    %ebp, %esp
pop    %ebp

可能会将堆栈指针恢复到函数入口处的状态。

Answer 2

好的，由于我看不到try部分，因此分析有点松散，但从标准调用约定判断，包含try的方法会将%esp保存到%ebp，减少%esp为局部变量腾出空间并运行保存%esp和%ebp的“尝试”代码。

通常，当函数退出时，它会在返回之前使用leave恢复这些更改。离开会将%ebp恢复为%esp，弹出%ebp并返回。这样可以确保%esp在保留局部变量的空间之前恢复到原点。

没有printf的版本中的问题是，如果没有先将leave内容恢复为%ebp，则%esp会弹出ret。 %esp指令将弹出一个局部变量并返回到该变量。不是最好的结果。

我怀疑是因为你的函数没有局部变量，所以编译器没有理由从%ebp恢复printf。由于%esp会在堆栈上保留空间，因此编译器会在该版本中知道在返回之前必须恢复0x0804847d <throw+35>: pop %ebp。

如果你想测试理论，只需编译成汇编程序，替换;

%esp

带有离开指令并汇总结果。它应该也能正常工作。

或者，我怀疑你可以在你的asm指令中向gcc表明%esp已被破坏，从而使它产生了休假。

编辑：显然将{{1}}标记为破坏在gcc中基本上是一个NOOP： - /

调用printf可以防止segfaulting

2 个答案: