为什么我在跟踪 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：

查找第二次调用 write，“call write”，在 secondaryCall 中 功能。在此行设置断点。据我所知是22。

在此行设置断点。

 break 22

在调试器中运行程序。

 run

程序将在您设置的断点处停止。 单步执行没有调试信息的代码。

  si 

您将在源布局中看到“[ 无可用源 ]”。所以你需要查看 拆解后的指令。

 layout asm

反复单步进入(si然后return/enter就会执行si命令 重复），直到您看到“sysenter”出现在屏幕的 asm 布局部分。 我试图将指令（包括它们的地址）从 asm 布局部分的顶部复制到并包括 sysenter 指令。

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

Answer 1

您正在追踪所谓的“虚拟动态共享对象”(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 方法
• SYSCALL 方法
• SYSENTER 方法 - 阅读注释了解为什么 %ecx、%edx 和 %ebp 被推送

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

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