为什么我在追踪 write() 时得到的结果与其他人不同？

Question

我正在做一些 x86 练习；我的作业让我在调试器中单步执行write() 库调用的汇编代码，直到我们到达SYSENTER 指令，但我得到的结果与我的一些同学不同。我看到导致SYSENTER 的是：

   │0xf7fdf421 <__kernel_vsyscall+1>        push   %edx                                                                                            
   │0xf7fdf422 <__kernel_vsyscall+2>        push   %ebp                                                                                            
   │0xf7fdf423 <__kernel_vsyscall+3>        mov    %esp,%ebp                                                                                       
   │0xf7fdf425 <__kernel_vsyscall+5>        sysenter    

这是我应该看到的吗？如果是这样，为什么它与我的一些同学看到的不同？ 在执行sysenter 指令之前，%edx 和 %ebp 寄存器是否也保存在堆栈中？ （根据我得到的答案会不会看起来不是这样，还是我错了？）

这是我作业的原始说明：

汇编代码：

.file    "A3Program2.c"
    .section    .rodata
.LC0:
    .string    "hello\n"
.LC1:
    .string    "xxxx\n"
    .text
.globl secondCall
    .type    secondCall, @function
secondCall:
    pushl    %ebp
    movl    %esp, %ebp
    subl    $40, %esp
    movl    $6, 8(%esp)
    movl    $.LC0, 4(%esp)
    movl    $1, (%esp)
    call    write
    movl    %eax, -12(%ebp)
    movl    $8, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    write
    addl    %eax, -12(%ebp)
    movl    12(%ebp), %eax
    movl    8(%ebp), %edx
    leal    (%edx,%eax), %eax
    addl    %eax, -12(%ebp)
    movl    -12(%ebp), %eax
    leave
    ret
    .size    secondCall, .-secondCall
.globl firstCall
    .type    firstCall, @function
firstCall:
    pushl    %ebp
    movl    %esp, %ebp
    subl    $40, %esp
    movl    $2, 4(%esp)
    movl    $4, (%esp)
    call    secondCall
    movl    %eax, -12(%ebp)
    movl    -12(%ebp), %eax
    leave
    ret
    .size    firstCall, .-firstCall
.globl main
    .type    main, @function
main:
    pushl    %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    call    firstCall
    movl    %eax, 12(%esp)
    movl    $0, %eax
    leave
    ret
    .size    main, .-main
    .ident    "GCC: (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5"
    .section    .note.GNU-stack,"",@progbits

以下说明适用于 Linux：

在 secondCall 中找到第二个调用 write 的行号，“call write” 功能。在这一行设置一个断点。据我说是22。

在此行设置断点。

 break 22

在调试器中运行程序。

 run

程序将在您设置的断点处停止。 进入没有调试信息的代码。

  si 

您将在源布局中看到“[No Source Available]”。所以你需要查看 反汇编指令。

 layout asm

反复 step into (si 然后回车/回车就会执行 si 命令 重复）直到您看到“sysenter”出现在屏幕的 asm 布局部分。 我正在尝试从 asm 布局部分的顶部复制指令（包括它们的地址），一直到并包括 sysenter 指令。

提示：您可以通过键入 Ctrl-x o 将键盘的焦点更改为命令区域。这 箭头键可用于恢复较早的命令的方式（它只是节省了一些 打字）。

Answer 1

您正在追踪所谓的'virtual dynamic shared object' (VDSO) - 其内容是Linux 内核的实现细节。有许多情况会导致 VDSO 的内容发生变化；因此这里没有一个正确的答案。

特别是在 32 位 x86 系统上，至少有三种不同的机制可用于进行系统调用：

• INT $0x80
• SYSCALL（最近的 AMD CPU）
• SYSENTER（最新的 Intel CPU）

您会注意到，只有INT $0x80 可以在所有 CPU 上运行（事实上，即使还有更现代的替代方案可用，内核也使其可用于遗留应用程序）；但是，它也很慢。内核将在启动时探测支持的版本，并选择使用最有效机制的 VDSO 版本。

因此，根据您的 CPU 型号，您可能会在 VDSO 中看到不同的代码 - 特别是，如果您有 AMD CPU，您可能会看到 SYSCALL 路径，如果您有一个非常旧的CPU 你甚至可能会看到INT $0x80 路径。如果您对其他人感到好奇，以下是源代码：

• INT $0x80 method
• SYSCALL method
• SYSENTER method - 阅读 cmets，了解为什么会推送 %ecx、%edx 和 %ebp

很可能，您实验室中获得不同结果的其他人拥有 AMD CPU 并且正在查看 SYSCALL 路径（或者他们有一台古董 PC，并且正在查看 INT $0x80 路径）。

还要注意，在 64 位进程中，SYSCALL 将被直接使用，根本不经过 VDSO。