|
From: Philippe W. <phi...@sk...> - 2010-06-01 19:44:21
|
> Actually, how does this work at all? I had problems finding a man page where it is exactly described > what should happen when a process waiting in a syscall is "interrupted" by ptrace. The man page > on my system says that on PTRACE_ATTACH/TRACEME, a SIGSTOP signal is sent to the process. Why > is this different to other signals? Why does the kernel need to do any special handling? SIGSTOP and SIGKILL are two special signals : the kernel never passes these signals to the process. If after SIGSTOP, the only actions done by gdb (or vgdb) is to read data, and then continue the process, then nothing special is to be done by the kernel: it just "continues" the syscall that the process was busy doing, because the ptraced process did not execute anything, and "stayed in the same kernel context". But in our case, after SIGSTOP, vgdb (or gdb, if you use gdb to "call code" in the debugged process) will "force" the process to execute some code (e.g. the gdbserver code) a.o. by setting the program counter register and then continuing the process. In this case, the ptraced process has thus left the kernel context in which it was busy executing a syscall. vgdb (or gdb), once the process has finished executed the "forced" code, will set back the program counter to the instruction where the syscall was "busy being done". But that is not exactly the same as just having SIGSTOPped and SIGCONTinued the process: to fully restore the "syscall context" implies the kernel to do something special only handled properly by a recent linux kernel. > > For PTRACE_ATTACH, the man page states "The calling process actually becomes the parent of the > child process for most purposes". I really would like external notifications to always work. > However, the previous sentences suggests that ptrace modifies the environment in a way which > is not always acceptable (?). The parent is changed only during the time the process is being ptraced, which in our case is during the execution of the "forced" code to be invoked (e.g. gdbserver code). Once vgdb (or gdb) detaches from the process, the original parent is restored. I believe all that is quite transparent, as this is used by gdb, strace + I did hundreds of "vgdb 'interrupts'" of firefox, without seeing anything special. > Just for my understanding: "more efficient" because it polls a memory address instead of doing > a system call? Effectively, that is the difference of efficiency. |