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.
Attachment:
pgp4E2m7u6xKA.pgp
Description: PGP signature