尝试单步执行带有陷阱标志和陷阱信号处理程序的程序时，vsyscall崩溃

我想创建一个程序执行的完整指令跟踪，以收集一些统计数据等。我首先尝试使用linux的ptrace功能逐步完成一个程序（使用教程）。这将创建两个进程，跟踪进程和调试器，它们通过信号进行通信。我每秒只得到16K左右的指令（在1.6GHz Atom上），所以这对于任何非平凡的事情来说都太慢了

我认为通过信号进行的进程间通信太慢，所以我尝试在与执行相同的过程中设置调试：设置陷阱标志，并创建信号处理程序。当一个软件中断被用来进行系统调用时，陷阱标志应该被保存，内核将使用它自己的标志——所以我认为。但我的程序不知怎么被信号陷阱杀死了

这是我设置的：

#include <stdio.h>
#include <unistd.h>
#include <signal.h>

int cycle = 0;
void trapHandler(int signum) {
  if (cycle % 262144 == 0) {
    write(STDOUT_FILENO," trap\n",6);
  }
  cycle += 1;
}

void startTrace() {
  // set up signal handler                                                                                                         
  signal(SIGTRAP, trapHandler);

  // set trap flag                                                                                                                 
  asm volatile("pushfl\n"
               "orl $0x100, (%esp)\n"
               "popfl\n"
               );
}

void printRock() {
  char* s = "Rock\n";
  asm(
      "movl $5, %%edx\n" // message length                                                                                         
      "movl %0, %%ecx\n" // message to write                                                                                       
      "movl $1, %%ebx\n" // file descriptor (stdout)                                                                               
      "movl $4, %%eax\n" // system call number (sys_write)                                                                         
      "int  $0x80\n"   // sycall                                                                                                   
      : // no output regs                                                                                                          
      : "r"(s) // input text                                                                                                       
      : "edx","ecx","ebx","eax"
      );
}

int main() {
  startTrace();

  // some computation                                                                                                              
  int x = 0;
  int i;
  for (i = 0; i < 100000; i++) {
    x += i*2;
  }

  printRock();
  write(STDOUT_FILENO,"Paper\n",6);
  write(STDOUT_FILENO,"Scissors\n",9);
}

因此，现在我们每秒得到大约250K条指令，仍然很慢，但可以执行非平凡的执行。但在两次写调用之间似乎发生了内核转储。在GDB中，我们可以看到它发生的地方：

Dump of assembler code for function __kernel_vsyscall:
   0xb76f3414 <+0>:  push   %ecx
   0xb76f3415 <+1>:  push   %edx
   0xb76f3416 <+2>:  push   %ebp
   0xb76f3417 <+3>:  mov    %esp,%ebp
   0xb76f3419 <+5>:  sysenter 
   0xb76f341b <+7>:  nop
   0xb76f341c <+8>:  nop
   0xb76f341d <+9>:  nop
   0xb76f341e <+10>: nop
   0xb76f341f <+11>: nop
   0xb76f3420 <+12>: nop
   0xb76f3421 <+13>: nop
   0xb76f3422 <+14>: int    $0x80
=> 0xb76f3424 <+16>: pop    %ebp
   0xb76f3425 <+17>: pop    %edx
   0xb76f3426 <+18>: pop    %ecx
   0xb76f3427 <+19>: ret 

函数uuu kernel\u vsyscall的汇编程序代码转储： 0xb76f3414:推送%ecx 0xb76f3415:推送%edx 0xb76f3416:推送%ebp 0xb76f3417:mov%esp，%ebp 0xb76f3419:系统输入 0xb76f341b:否 0xb76f341c:nop 0xb76f341d:否 0xb76f341e:否 0xb76f341f:nop 0xb76f3420:nop 0xb76f3421:nop 0xb76f3422:int$0x80 =>0xb76f3424:弹出%ebp 0xb76f3425:弹出%edx 0xb76f3426:弹出%ecx 0xb76f3427:ret 以及回溯：

Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  0xb77c5424 in __kernel_vsyscall ()
#1  0xb76d0553 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:81
#2  0x0804847d in trapHandler (signum=5) at count.c:8
#3  <signal handler called>
#4  0xb77c5424 in __kernel_vsyscall ()
#5  0xb76d0553 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:81
#6  0x08048537 in main () at count.c:49

程序以信号信号陷阱、跟踪/断点陷阱终止。
#内核vsyscall（）中的0 0xb77c5424
#位于../sysdeps/unix/syscall template.S:81处的1 0xb76d0553 in\uu write\u nocancel（）
#2 0x0804847d在trapHandler（signum=5）中计数。c:8
#3  
#内核vsyscall（）中的4 0xb77c5424
#位于../sysdeps/unix/syscall template.S:81处的5 0xb76d0553英寸写入取消（）
#6 0x08048537位于count.c:49处的main（）中

通过

int80

进行的系统调用似乎没有问题，但是写调用以某种方式使用内核的VIDSO/vsyscall中断（我不知道这个功能，更详细地描述）。它可能与使用

sysenter

而不是

int80

有关，可能陷阱标志在进入内核时仍然存在。我不太明白递归的

\uuu内核\uvsyscall

调用是怎么回事。我也不明白为什么在

\uu kernel\u vsyscall

函数中有

int80

调用

有人有什么建议发生了什么，以及如何解决这个问题吗？也许可以禁用VDSO/vsysicall？或者是否可以使用使用

int 80

而不是

syscenter

的函数来覆盖

\uu内核vsyscall

函数？

回答自己的问题。 我没有弄清楚发生了什么，也没有详细解释，但我找到了一个解决办法：禁用VDSO。这可以通过

sudo sysctl vm.vdso_enabled=0

这样，整个程序的单步执行就可以工作了，包括跨系统调用的单步执行。免责声明：如果情况不好，不要怪我

编辑：在更新我的Linux（32位x86）很久之后，这个错误不再发生。也许是一个已经修复的bug

sudo sysctl vm.vdso_enabled=0