On Fri, Sep 26, 2008 at 08:44:29PM -0700, Bill Stouder-Studenmund wrote: [...] > I think the problem is that something's wrong with how user contexts are > handled in upcall delivery. This _used_ to work, so I'm not sure what > changed to trigger the problem.I am also not sure what's different to > cause repeated applications with the 4.1 libpthread to not have problems > that the 3.0 libpthread barfs on. > > 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. 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). 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. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpvH2zQEESsL.pgp
Description: PGP signature