From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 27 17:34:57 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04EB916A4DA; Thu, 27 Jul 2006 17:34:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3972543D46; Thu, 27 Jul 2006 17:34:56 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6RHYrn3078521; Thu, 27 Jul 2006 13:34:54 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 27 Jul 2006 11:21:16 -0400 User-Agent: KMail/1.9.1 References: <200607221914.15826.lofi@freebsd.org> <200607250358.21457.tijl@ulyssis.org> In-Reply-To: <200607250358.21457.tijl@ulyssis.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607271121.17313.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 27 Jul 2006 13:34:55 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1623/Wed Jul 26 18:35:11 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Daniel Eischen , Tijl Coosemans , freebsd-emulation@freebsd.org, Michael Nottebrock Subject: Re: WINE vs. FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 17:34:57 -0000 On Monday 24 July 2006 21:58, Tijl Coosemans wrote: > On Monday 24 July 2006 18:49, Daniel Eischen wrote: > > On Mon, 24 Jul 2006, Tijl Coosemans wrote: > > > On Monday 24 July 2006 17:39, Daniel Eischen wrote: > > >> On Mon, 24 Jul 2006, Tijl Coosemans wrote: > > >>> I've attached two patches that accomplish this, but this seems to > > >>> trigger other problems, so use at your own risk. If you want to > > >>> try them, place them in the port's files/ directory and add a > > >>> line containing "USE_AUTOTOOLS= autoconf:259" to the Makefile. > > >>> This seems to break wine+libpthread, so I've also changed the > > >>> port to use libthr instead. > > >>> > > >>> For the libpthread experts, I haven't investigated that much > > >>> further yet, but libpthread seems to fail in create_stack() from > > >>> _pthread_create() from _thr_start_sig_daemon(). > > >> > > >> See my response to this in a previous reply to this thread. > > >> libthr and libpthread use LDT's for TLS. WINE is stomping on them > > >> because it doesn't properly create LDTs. This is not a problem > > >> with either of the thread libraries and this issue has been known > > >> ever since we implemented TLS years ago. > > > > > > And as I stated later on in that thread, I don't see where > > > libpthread and libthr still use LDT entries. As far as I understand > > > the code, instead of using an LDT entry per thread (as it sure used > > > to be), only one single GDT entry is used whose base address is > > > updated during a context switch. Looking at the cvs history, it has > > > been working like this since a couple commits of Peter Wemm about a > > > year ago. > > > > > > And if nothing but Wine uses the LDT, Wine's static allocation of > > > LDT entries can't be the problem. > > > > Look, we use %gs for TLS, period. Go see > > libpthread/arch/i386/i386/pthread_md.c for how libpthread does it. > > TLS would not work without setting aside a register for the threads > > library (and rtld) to use. > > Aaarrrrgghhh :) > > What you say is true of course, but %gs points to a GDT entry, not LDT. > libpthread and libthr no longer use LDT entries... > > There would be a problem of course if Wine or Windows programs > change %gs. Wine does seem to touch %gs but I've never actually seen it > change. It's always 0x001B, which is the correct value (GUGS_SEL). > > However, Wine/Windows uses %fs for TLS and it appears that the FreeBSD > kernel doesn't preserve it. It always ends up pointing to GUDATA_SEL. The kernel should preserve %fs across syscalls, traps, and faults. Can you point to a specific case where %fs is not preserved? It sounds like %fs is never set to a value in Wine. -- John Baldwin