This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: {make,set,swap}context broken on powerpc32
- From: Paul Mackerras <paulus at samba dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Steven Munroe <munroesj at us dot ibm dot com>, libc-alpha at sources dot redhat dot com
- Date: Wed, 13 Dec 2006 13:43:31 +1100
- Subject: Re: {make,set,swap}context broken on powerpc32
- References: <20061212130526.GC29911@devserv.devel.redhat.com>
Jakub Jelinek writes:
> The following testcase crashes on powerpc32 with CVS glibc (but glibc 2.5 as
> well) and 2.6.18 kernel, when glibc is configured for 2.6.0+ kernel
> (i.e. __ASSUME_SWAPCONTEXT_SYSCALL). The problem is in clobberring r2 (== TLS)
> register.
> One thing is that swapcontext syscall restores r2 (for 32-bit processes)
> from the saved registers.
I find it hard to see how that could be happening, because the kernel
code explicitly preserves r2. In arch/powerpc/kernel/signal_32.c,
sys_swapcontext calls do_setcontext with `sig' == 0, which calls
restore_user_regs with the same `sig' argument, which then does this:
/*
* restore general registers but not including MSR or SOFTE. Also
* take care of keeping r2 (TLS) intact if not a signal
*/
if (!sig)
save_r2 = (unsigned int)regs->gpr[2];
err = restore_general_regs(regs, sr);
err |= __get_user(msr, &sr->mc_gregs[PT_MSR]);
if (!sig)
regs->gpr[2] = (unsigned long) save_r2;
The 64-bit sys_swapcontext (in signal_64.c) similarly avoids modifying
r13, using a slightly different mechanism.
That's assuming that glibc is in fact using the sys_swapcontext system
call. If it's using sys_rt_sigreturn instead, then yes that will
restore r2 from the saved registers.
Could you strace your test program and see whether it is using
sys_swapcontext or sys_rt_sigreturn?
I just wrote a little test program to call sys_swapcontext directly
and check what happens to r2, and it appears to be doing the right
thing (i.e. sys_swapcontext with non-NULL second argument is not
modifying r2). This is with a 2.6.18-rc7 ppc64 kernel, and a 32-bit
user process. I'll try a ppc32 kernel shortly.
Regards,
Paul.