On Sat, Sep 27, 2008 at 06:33:46AM +0200, Quentin Garnier wrote: > On Fri, Sep 26, 2008 at 08:44:29PM -0700, Bill Stouder-Studenmund wrote: > [...] > > > > I would appreciate debugging assistance. The exact specifics of upcall > > delivery are things that I'd hoped to leave as-was & have work. It is the > > one area I'm not too strong at. > > I have bad news, at least for 3.x users. I know very well the > difference between 3.x and 4.x because I did the commit (and the lengthy > debugging before that) that produces the behaviour. > > libpthread used to use hard-coded values for the initial context of new > threads or upcall handlers. That didn't work under COMPAT_NETBSD32 > because the order of the GDT entries was different, thus the hard-coded > values were illegal. So I changed that to use the current values for > the segment registers. So the NetBSD 3.X libpthread had a problem w/ COMPAT_NETBSD32, and the NetBSD 4.X did not. But non-COMPAT_NETBSD32 usage didn't notice a difference. > What happens now is that the order of GDT entries changed in i386. See > revision 1.42 of sys/arch/i386/include/segments.h, and that make the > value of CS used by 3.x's libpthread invalid (selecting GUDATA instead > of GUCODE). Then this change, between 4.x and 5.x, changed things such that non-COMPAT_NETBSD32 now notices the issue fixed above. > Andrew will have to confirm, but the comments say that the new order is > mandatory for sysenter. That said, AFAIK, we don't use sysenter by > default. The only way to use it is to compile libc with -DI686_LIBC, so > we have the option of providing the compatibility as long as the user > accepts not to use sysenter. My "perfect world" solution would be to make the sysenter-compatible reshuffling an option and make COMPAT_30_PTHREAD or some such another option, and make the two incompatible. That way an admin can clearly select which way to go. If either were a default, I'd make the sysenter one default. :-) The upshot, though, is that this means that revivesa didn't break this. So does anyone else have any issues that should be examined before a merge? The only one I see is to verify that I'm not really seeing a crash of named on boot. Take care, Bill
Attachment:
pgp9orJCG9O3A.pgp
Description: PGP signature