tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Status of revivesa

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

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 - -
"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

Home | Main Index | Thread Index | Old Index