From owner-freebsd-emulation@FreeBSD.ORG Tue Jul 25 01:58:36 2006 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1373C16A4DA; Tue, 25 Jul 2006 01:58:36 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from outmx001.isp.belgacom.be (outmx001.isp.belgacom.be [195.238.5.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 541ED43D45; Tue, 25 Jul 2006 01:58:35 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx001.isp.belgacom.be (localhost [127.0.0.1]) by outmx001.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k6P1wXqR031458; Tue, 25 Jul 2006 03:58:33 +0200 (envelope-from ) Received: from kalimero.kotnet.org (233.121-247-81.adsl-dyn.isp.belgacom.be [81.247.121.233]) by outmx001.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k6P1wSs4031404; Tue, 25 Jul 2006 03:58:28 +0200 (envelope-from ) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.6/8.13.6) with ESMTP id k6P1wLYs099116; Tue, 25 Jul 2006 03:58:22 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org, Daniel Eischen Date: Tue, 25 Jul 2006 03:58:06 +0200 User-Agent: KMail/1.9.3 References: <200607221914.15826.lofi@freebsd.org> <200607241839.28229.tijl@ulyssis.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2198738.aAC9hlQsmE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607250358.21457.tijl@ulyssis.org> Cc: freebsd-hackers@freebsd.org, Michael Nottebrock Subject: Re: WINE vs. FreeBSD X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 01:58:36 -0000 --nextPart2198738.aAC9hlQsmE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=3D 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.=20 > >> 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.=20 > 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.=20 libpthread and libthr no longer use LDT entries... There would be a problem of course if Wine or Windows programs=20 change %gs. Wine does seem to touch %gs but I've never actually seen it=20 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=20 kernel doesn't preserve it. It always ends up pointing to GUDATA_SEL. --nextPart2198738.aAC9hlQsmE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQBExXq9dMR2xnarec8RAqulAJ4yxbyI98xm5NNR435SSjVRexBPGQCePcQC 2CrH4OPfAvSy7sojjFCyfg8= =hOSN -----END PGP SIGNATURE----- --nextPart2198738.aAC9hlQsmE--