Fedora utrace changes break PPC GDB

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Hello,

I've been testing GDB on a PowerPC system running a Fedora 7 kernel,
and there are some regressions that appear to have been introduced
by the ptrace-on-utrace emulation layer that is now included in
Fedora.

Specifically, there are the following two problems (which also seem
to still be present in a current Fedora development kernel):

- PTRACE_SET_DEBUGREG ABI change

  In mainline kernels, PTRACE_SET_DEBUGREG takes an immediate 
  argument (like e.g. PTRACE_POKEUSR).  However, the Fedora code has:

        case PTRACE_GET_DEBUGREG:
        case PTRACE_SET_DEBUGREG:
                return ptrace_onereg_access(child, engine,
                                            utrace_native_view(current), 3,
                                            addr, (unsigned long __user *)data,
                                            *request == PTRACE_SET_DEBUGREG);

  which assumes the "data" argument is a *pointer* to the data,
  instead of the value itself.

  This breaks hardware watchpoint support completely.

- vrsave register access 

  The mainline kernel uses the following function to implement
  the PTRACE_GETVRREGS routine:

        /* copy AltiVec registers VR[0] .. VR[31] */
        regsize = 32 * sizeof(vector128);
        if (copy_to_user(data, task->thread.vr, regsize))
                return -EFAULT;
        data += (regsize / sizeof(unsigned long));

        /* copy VSCR */
        regsize = 1 * sizeof(vector128);
        if (copy_to_user(data, &task->thread.vscr, regsize))
                return -EFAULT;
        data += (regsize / sizeof(unsigned long));

        /* copy VRSAVE */
        if (put_user(task->thread.vrsave, (u32 __user *)data))
                return -EFAULT;

  Note that vscr and vrsave are provided in distinct fields of
  the thread struct:

        /* Complete AltiVec register set */
        vector128       vr[32] __attribute((aligned(16)));
        /* AltiVec status */
        vector128       vscr __attribute((aligned(16)));
        unsigned long   vrsave;
        int             used_vr;        /* set if process has used altivec */


  However, the utrace emulation layer in Fedora does

        case PTRACE_GETVRREGS:
                return ptrace_whole_regset(child, engine, data, 2, 0);
        case PTRACE_SETVRREGS:
                return ptrace_whole_regset(child, engine, data, 2, 1);

  using the following "regset" and access routines

#ifdef CONFIG_ALTIVEC
        {
                .n = 33*4+1, .size = sizeof(u32), .align = sizeof(u32),
                .active = vrregs_active, .get = vrregs_get, .set = vrregs_set
        },
#endif

static int
vrregs_get(struct task_struct *target,
           const struct utrace_regset *regset,
           unsigned int pos, unsigned int count,
           void *kbuf, void __user *ubuf)
{
        BUILD_BUG_ON(offsetof(struct thread_struct, vscr)
                     != offsetof(struct thread_struct, vr[32]));
        BUILD_BUG_ON(offsetof(struct thread_struct, vscr) + sizeof(vector128)
                     != offsetof(struct thread_struct, vrsave));

        flush_altivec_to_thread(target);

        return utrace_regset_copyout(&pos, &count, &kbuf, &ubuf,
                                     &target->thread.vr, 0, -1);
}

   This has the effect of simply accessing 33*4+1 "u32" values starting
   at &target->thread.vr

   Now, given the declaration above, the vr field is only 32 * 16 bytes
   long, so this is not really legal C in any case.  Even so, access to
   the vscr field happens to actually work correctly, as it immediately
   following vr (and there happens to be no padding).

   However, vrsave is accessed incorrectly on a 64-bit kernel: its value
   resides in the low 32 bits of the "unsigned long", and the copyout
   accesses the high 32 bits ...   (The BUILD_BUG_ON doesn't help.)

   This has the effect of GDB always reading vrsave as 0, even after
   attempting to set it to some other value.  (Every restart of the
   target process will apparently cause the upper 32 bit to be reset.)


Any suggestions how to get this fixed?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com