ia64: Fix a ptrace-bug that caused "strace -f" to crash the inferior
process. The root-cause of the problem was that ptrace() tried to copy the portion of the register backing store that landed on the kernel stack back to users-space, but the resulting state was inconsistent if the inferior process was in the middle of a system-call (as would always be the case for strace). The solution is to avoid all needless copying and to instead ensure that when accessing a memory location that may belong to a thread's register-backing store, we attach to that particular thread, rather than the thread identified by the PID argument. If the thread happens to be unattachable, we fall back to using the thread identified by the PID argument. This should have the desired effect if the thread has terminated already and if the thread is running while ptrace() is trying to access its state, all bets are off anyhow and there are no coherency guarantees. In other words, this should be doing the right thing under all circumstances. The patch also fixes the case where PT_AR_BSP and/or PT_CFM are written while the inferior process is in the middle of a system call. This makes arguments passed to GDB inferior calls come out right. The patch was tested with strace -f and the GDB testsuite, which showed no regressions compared to the previous version of the kernel.
Showing
This diff is collapsed.
Please register or sign in to comment