linuxolator: tls_test results amd64

Jung-uk Kim jkim at FreeBSD.org
Tue Jan 23 23:12:57 UTC 2007


On Tuesday 23 January 2007 05:59 pm, Tijl Coosemans wrote:
> On Tuesday 23 January 2007 23:43, Tijl Coosemans wrote:
> > On Tuesday 23 January 2007 21:55, Jung-uk Kim wrote:
> > > On Tuesday 23 January 2007 03:13 pm, Tijl Coosemans wrote:
> > > > On Tuesday 23 January 2007 20:00, Jung-uk Kim wrote:
> > > > > Second problem is MSR_KGSBASE is scrubbed by something
> > > > > during context switch, i.e., it becomes 0 some times.
> > >
> > > Saved pcb_gsbase seems always correct.  MSR_KGSBASE is not,
> > > which is supposedly swapped with MSR_GSBASE via swapgs.  Maybe
> > > I am confused, or maybe my CPU is too old (it's C0 stepping and
> > > I know there are some segmentation issues with the revision)
> > > but that's what I see. I need more time for testing (or
> > > resting?).
> >
> > Ok, I understand why pcb_gsbase is always correct. It is never
> > written to except for cpu_set_user_tls, i386_set_gsbase and
> > set_thread_area. cpu_switch only reads from it to restore gsbase.
> > At least, that's what cpu_switch does in case of 64 bit programs,
> > not 32 bit it seems. Why is that? Why is there a jmp on line 186
> > in sys/amd64/amd64/cpu_switch.S?
>
> This doesn't explain why gsbase becomes 0 by the way. I still think
> that's because glibc does "mov index,%gs" after calling
> set_thread_area.

That's correct.  See:

http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/linuxthreads/linuxthreads/sysdeps/i386/tls.h?rev=1.39&content-type=text/plain&cvsroot=glibc

Jung-uk Kim


More information about the freebsd-emulation mailing list