On Fri, Sep 26, 2008 at 11:15:23PM -0700, Bill Stouder-Studenmund wrote: > 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. Yes, because the order in the GDT wasn't changed. The problem of netbsd32 is that said order was different on amd64 and on i386. > > 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. It's not "now". If I hadn't made that change, even 4.x libpthread would just not work on current i386! > > 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. :-) I see two issues with that (though I'd really like to use that solution): - there may be 3rd party application that play the same naughty games as the old libpthread, e.g. by storing a ucontext at some point and re-using it later. I think of interpreted languages that can be compiled for faster execution. COMPAT_30_PTHREAD would introduce a very weird failure case. - if we ever decide to make a libci686 and load it through ld.so.conf games, COMPAT_30_NETBSD will become a real burden. The first point is not so bad; I don't even have any evidence such a bad application exists (but wandering around pkgsrc you see scary stuff though). As for the second one, it won't apply to 5.0 anyway, so we're safe for a while, and we might have a way out later (for instance, if we are to ever bump libc, we could bury SA again). > 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. Well, at least that one is a different issue. -- 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.
Description: PGP signature