Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jan 2007 09:18:10 +0100
From:      Divacky Roman <xdivac02@stud.fit.vutbr.cz>
To:        Tijl Coosemans <tijl@ulyssis.org>
Cc:        freebsd-emulation@freebsd.org, jkim@freebsd.org
Subject:   Re: linuxolator: tls_test results amd64
Message-ID:  <20070122081810.GA42976@stud.fit.vutbr.cz>
In-Reply-To: <200701220001.22404.tijl@ulyssis.org>
References:  <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <20070121185445.GA88090@stud.fit.vutbr.cz> <200701220001.22404.tijl@ulyssis.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 22, 2007 at 12:01:19AM +0100, Tijl Coosemans wrote:
> On Sunday 21 January 2007 19:54, Divacky Roman wrote:
> > On Sun, Jan 21, 2007 at 12:41:02PM -0600, Scot Hetzel wrote:
> > > Divacky Roman asked me to update my sources to the latest P4 patches
> > > and run the tls_test program.  Below are the results:
> > > 
> > > hp010 / # ./tls_test
> > > 
> > > doing 1st set_thread_area():
> > > ====> got GDT selector: 0x0 --- TEST PASSED.
> > > 
> > > reading first byte of [0x00000000] TLS:
> > > ====> 123 --- TEST PASSED.
> > > 
> > > doing 2nd set_thread_area():
> > > ====> got GDT selector: 0x4 --- TEST PASSED.
> > > context-switching once ...
> > > 
> > > reading first byte of 4K [0x0804aca0] TLS:
> > > Segmentation fault (core dumped)
> > 
> > this means that we are able to set up the TLS for the very first
> > time but not any other time.
> > 
> > can someone explain this?
> > 
> > the tls_test program is at
> > 
> > www.stud.fit.vutbr.cz/~xdivac02/tls_test.c
> 
> I don't have an amd64 box, so I can only guess, but I think it's your
> test that's bugged and not your tls implementation.
> 
> Your test uses FS and your tls implementation uses GS and while they
> each point to the same GDT entry they don't end up pointing to the
> same addresses because your tls implementation doesn't touch the GDT
> entry at all. It simply (and correctly as far as I can tell) changes
> the upper 32 bits of GS (using wrmsr).

yeah, I thought about this as well and we might test it but

1) why  the first test succeeds?
2) why real apps (ie. using %gs) show the very same behaviour (first program
works then it doesnt)
 
 
> So what you should change in your test I believe, is remove the
> initseg() function and every use of it and in __readseg() and
> __writeseg() use gs instead of fs.

to be honest I dont think this is possible. we have to support every
program written for 32bit linux. its no way to change userland apps
if we could I'd better port them to fbsd and avoid linuxulator at all :)

amd64 running 32bit program runs in a special "compatibility mode". I dont
know much about it but I guess it at least "emulates" things like GDT etc.
otherwise a lot would not be possible. imho

roman



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070122081810.GA42976>