|
From: Josef W. <Jos...@gm...> - 2010-06-02 00:42:51
|
On Tuesday 01 June 2010, Philippe Waroquiers wrote: > > 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. Ok. > 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. I still do not understand why vgdb can "force" the process to execute code by just changing the program counter. Is this PC change detected by the kernel and interpreted as a request to put the process back into user context (if it was waiting in a syscall), as it is needed to result in execution of the code? > > 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. Ok, that sounds good. Josef |