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.