【发布时间】：2015-01-20 17:49:47
【问题描述】：
我想创建一个程序执行的完整指令跟踪，收集一些统计信息等。我首先尝试使用 linux 的 ptrace 功能来逐步执行程序（使用教程 here）。这将创建两个进程，一个被跟踪的进程和一个调试器，它们通过信号进行通信。我每秒只有大约 16K 条指令（在 1.6GHz Atom 上），所以这对于任何重要的事情来说都太慢了。
我认为通过信号的进程间通信太慢了，所以我尝试在与执行相同的进程中设置调试：设置陷阱标志，并创建信号处理程序。当使用软件中断进行系统调用时，应保存陷阱标志，内核将使用它自己的标志 - 所以我想。但是我的程序不知何故被信号 SIGTRAP 杀死了。
这是我设置的：
#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);
}
运行时，会给出：
trap
trap
trap
Rock
Paper
trap
Trace/breakpoint trap (core dumped)
所以现在我们每秒获得大约 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
还有回溯：
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
似乎通过int 80 发生的系统调用很好，但是写入调用以某种方式使用了内核的 VIDSO/vsyscall 中断（我不知道这个功能，更详细地描述了here）。它可能与使用sysenter 而不是int 80 相关，可能在进入内核时陷阱标志仍然存在。我不太明白递归 __kernel_vsyscall 调用的情况。我也不明白为什么在__kernel_vsyscall 函数中有一个int 80 调用。
有没有人建议发生了什么，以及如何解决这个问题？也许可以禁用 VDSO/vsyscall？或者是否可以用使用int 80 而不是sysenter 的函数覆盖__kernel_vsyscall 函数？
【问题讨论】：
标签： c linux signals system-calls