This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Fedora utrace changes break PPC GDB
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: roland at redhat dot com, gdb at sourceware dot org
- Date: Mon, 29 Oct 2007 22:21:35 +0100 (CET)
- Subject: Fedora utrace changes break PPC GDB
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