On Thu, 19 Sep 2002, Julian Elischer wrote: > On Thu, 19 Sep 2002, Daniel Eischen wrote: > > > On Wed, 18 Sep 2002, Julian Elischer wrote: > > > > > threads is broken right now.. > > > due to a miscommunicatin,. the kernel and the threads library have > > > a disagreement regarding something.. > > > Unfortunatly the person to slap up over this is offline for aday or > > > so.. > > > please be patient for a day or so (we hope). > > > > I think it's because libc_r has been disconnected from the > > build: > > > > revision 1.143 > > date: 2002/09/17 07:32:36; author: peter; state: Exp; lines: +1 -1 > > Add i386 to the list of architectures that libc_r is broken on. This > > effectively removes pppctl from the build for now. It only compiles on > > alpha now (now ironic). > > > > And the i386 mcontext_t is now bigger because we account for the > > newer SSE (?) format FP register sets. Older libc_r's used ucontext_t's > > that were smaller and manually save and restore FP state into > > areas of ucontext_t which mc_len and mc_fpformat now occupy. > > so does that code still exist?
Because libc_r is still disconnected from the build, the older library is still left in place. This library messes with a ucontext (a sigcontext sent to userland from the kernel via a signal handler) that corrupts it (invalidates it) so that when it returns to the kernel from the signal frame (sigreturn), the kernel returns an error or doesn't restore the FP state (see sigreturn() in machdep.c; it calls set_fpcontext() which checks mc_fpformat). A freshly built libc_r with the patches I sent should not mess with any FP state in a ucontext and should avoid the problem. It doesn't have to save and restore the FP state anymore because the i386 code now correctly saves and restores the FP state when sending a signal. Or at least that's the intent of the new code. > > The kernel uses these to validate a context and returns an > > error if these fields aren't valid. > > so, we need to change the kernel too right? No, the kernel is doing the right thing; it's just that the old userland library isn't yet seeing a ucontext in the same way the kernel is. > > The fix is to remove the two calls to FP_SAVE_UC and FP_RESTORE_UC > > in libc_r/uthread/uthread_kern.c. And to also hook libc_r back > > into the build (src/lib/Makefile). > > If we remove the calls, is the original code still present? > or did that get removed? Removing the calls should make it build again, and hooking it back into the build/install process will update the old libc_r so that it works with a new kernel. Threads won't work totally right with the new library and an old kernel because the FP state won't be saved/restored by either the kernel or the library. Is this what you meant? -- Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
