Shigeyuki Fukushima <shige@NetBSD.org> writes:

> I think that we shouldn't apply this PR patch.
> And I think that the point of this problem is the following one thing:
> 
> Why is there a magic number (0xd032) in
> src/lib/libpthread/arch/powerpc/pthread_md.h.
> 
> 
> What is the best approach to solve it?

The core of this problem is that setmcontext() uses PSL_USEROK_P(),
which differs among PowerPC CPUs, and returns an error if the value
passed in (by the setcontext syscall) doesn't conform. I chose that
magic value to work on OEA CPUs; at the time I wrote it, I did not
realize that it was OEA-only.

There are two approaches to solving the problem:

1. Export a usable magic/default value for the MSR to userland,
   perhaps by a sysctl. libpthread will retrieve that value and use it
   here.

2. Make setmcontext() fix up the passed-in MSR value instead of
   erroring out. Libpthread then does not need the magic value at
   all. I think this is the more useful approach; it hides the
   machine-dependance entirely.

Here is a patch for #2:

Index: sig_machdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/powerpc/powerpc/sig_machdep.c,v
retrieving revision 1.24
diff -u -r1.24 sig_machdep.c
--- sig_machdep.c	11 Dec 2005 12:18:46 -0000	1.24
+++ sig_machdep.c	13 Mar 2006 17:51:03 -0000
@@ -223,8 +223,11 @@
 
 	/* Restore GPR context, if any. */
 	if (flags & _UC_CPU) {
-		if (!PSL_USEROK_P(gr[_REG_MSR]))
-			return (EINVAL);
+		/*
+		 * Accept all user-settable bits without complaint; userland
+		 * should not need to know the machine-specific MSR value.
+		 */
+		gr[_REG_MSR] = (gr[_REG_MSR] & PSL_USERMOD) | PSL_USERSET;
 
 #ifdef PPC_HAVE_FPU
 		/*


        - Nathan