From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 21 15:46:15 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4726616A404 for ; Sun, 21 Jan 2007 15:46:15 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from nibbel.kulnet.kuleuven.ac.be (nibbel.kulnet.kuleuven.ac.be [134.58.240.41]) by mx1.freebsd.org (Postfix) with ESMTP id 09C3313C45E for ; Sun, 21 Jan 2007 15:46:14 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 7F55D4D34D for ; Sun, 21 Jan 2007 16:46:13 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id EEC404D33A for ; Sun, 21 Jan 2007 16:46:12 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id C07002CAADA for ; Sun, 21 Jan 2007 16:46:09 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0LFk8Dh024277 for ; Sun, 21 Jan 2007 16:46:08 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Sun, 21 Jan 2007 16:46:04 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701211646.07586.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Subject: linux ldd does work 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: Sun, 21 Jan 2007 15:46:15 -0000 I noticed on the wiki under misc bugs, it says that linux ldd doesn't work (prints nothing). It does work when you run it with the linux sh, but only on DSOs it seems. /compat/linux/bin/sh /compat/linux/usr/bin/ldd From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 21 18:33:54 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05E3D16A405 for ; Sun, 21 Jan 2007 18:33:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id B608713C474 for ; Sun, 21 Jan 2007 18:33:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5CC95.dip.t-dialin.net [84.165.204.149]) by redbull.bpaserver.net (Postfix) with ESMTP id 96D922E0A7; Sun, 21 Jan 2007 19:42:34 +0100 (CET) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by outgoing.leidinger.net (Postfix) with ESMTP id AC6A55B4853; Sun, 21 Jan 2007 19:33:43 +0100 (CET) Date: Sun, 21 Jan 2007 19:33:43 +0100 From: Alexander Leidinger To: Tijl Coosemans Message-ID: <20070121193343.2ca3a487@Magellan.Leidinger.net> In-Reply-To: <200701211646.07586.tijl@ulyssis.org> References: <200701211646.07586.tijl@ulyssis.org> X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.8; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-emulation@freebsd.org Subject: Re: linux ldd does work 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: Sun, 21 Jan 2007 18:33:54 -0000 Quoting Tijl Coosemans (Sun, 21 Jan 2007 16:46:04 +0100): > I noticed on the wiki under misc bugs, it says that linux ldd doesn't > work (prints nothing). It does work when you run it with the linux sh, > but only on DSOs it seems. >=20 > /compat/linux/bin/sh /compat/linux/usr/bin/ldd Thanks: info in the wiki enhanced. Bye, Alexander. --=20 3: Polymorphie Der Fehler tritt in vielerlei Gestalt auf. (Kristian K=C3=B6hntop= p) http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 21 18:41:05 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3621116A408 for ; Sun, 21 Jan 2007 18:41:05 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id C8CE213C461 for ; Sun, 21 Jan 2007 18:41:04 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so789014uge for ; Sun, 21 Jan 2007 10:41:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=HgK7EArLO8ZydKoO3Px1ygonN3l1l+FTHCeXj0P/VLmKyA4c7u2224/4av+IWjDeEp3HFdMGS0rOURmfYHwEnkEFeb6VkZj5Nt+t050vUwIt33LYNrbbIa5uBnZX1UdugLrvD6RWWBO8mIp7IVMEfRe5NO4olyNn/1keKkZsIr0= Received: by 10.82.139.17 with SMTP id m17mr3313641bud.1169404862869; Sun, 21 Jan 2007 10:41:02 -0800 (PST) Received: by 10.82.186.2 with HTTP; Sun, 21 Jan 2007 10:41:02 -0800 (PST) Message-ID: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> Date: Sun, 21 Jan 2007 12:41:02 -0600 From: "Scot Hetzel" To: freebsd-emulation@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: jkim@freebsd.org Subject: linuxolator: tls_test results amd64 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: Sun, 21 Jan 2007 18:41:05 -0000 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) Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 21 18:54:47 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF7DC16A401; Sun, 21 Jan 2007 18:54:47 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 83CA513C441; Sun, 21 Jan 2007 18:54:47 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0LIsk8e088300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jan 2007 19:54:46 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0LIsjuj088299; Sun, 21 Jan 2007 19:54:45 +0100 (CET) Date: Sun, 21 Jan 2007 19:54:45 +0100 From: Divacky Roman To: jkim@freebsd.org Message-ID: <20070121185445.GA88090@stud.fit.vutbr.cz> References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: freebsd-emulation@freebsd.org Subject: Re: linuxolator: tls_test results amd64 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: Sun, 21 Jan 2007 18:54:48 -0000 the tls_test program is at www.stud.fit.vutbr.cz/~xdivac02/tls_test.c 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? From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 21 22:20:59 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DD4316A403 for ; Sun, 21 Jan 2007 22:20:59 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 91FED13C455 for ; Sun, 21 Jan 2007 22:20:58 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0LMKuuJ007875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jan 2007 23:20:56 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0LMKuC5007874; Sun, 21 Jan 2007 23:20:56 +0100 (CET) Date: Sun, 21 Jan 2007 23:20:56 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070121222056.GA7798@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org Subject: amd64-tls: a wild idea to test 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: Sun, 21 Jan 2007 22:20:59 -0000 hi.. can you try this patch? its very wild idea but miracles happen :) --- /tmp/tmp.5878.0 Sun Jan 21 23:20:12 2007 +++ /root/projects/linuxolator/src/sys/amd64/linux32/linux32_machdep.c Sun Jan 21 23:20:04 2007 @@ -1298,8 +1298,8 @@ critical_enter(); /* set %gs */ + wrmsr(MSR_KGSBASE, (register_t) info.base_addr); td->td_pcb->pcb_gsbase = (register_t)info.base_addr; - wrmsr(MSR_KGSBASE, td->td_pcb->pcb_gsbase); critical_exit(); (test with tls_test please) roman From owner-freebsd-emulation@FreeBSD.ORG Sun Jan 21 23:01:28 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0728316A401; Sun, 21 Jan 2007 23:01:28 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from rusty.kulnet.kuleuven.ac.be (rusty.kulnet.kuleuven.ac.be [134.58.240.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9093113C44C; Sun, 21 Jan 2007 23:01:27 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 8660D1D77DE; Mon, 22 Jan 2007 00:01:26 +0100 (CET) Received: from smtps01 (octavianus.kulnet.kuleuven.ac.be [134.58.240.71]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 9C5E91D771B; Mon, 22 Jan 2007 00:01:25 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtps01 (Postfix) with ESMTP id E45322E68CC; Mon, 22 Jan 2007 00:01:24 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0LN1NYV031256; Mon, 22 Jan 2007 00:01:23 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Mon, 22 Jan 2007 00:01:19 +0100 User-Agent: KMail/1.9.5 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <20070121185445.GA88090@stud.fit.vutbr.cz> In-Reply-To: <20070121185445.GA88090@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701220001.22404.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: jkim@freebsd.org Subject: Re: linuxolator: tls_test results amd64 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: Sun, 21 Jan 2007 23:01:28 -0000 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). 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. http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/x86-64_overview.pdf page 43, Special Treatment of FS and GS segments From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 00:43:42 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B09716A400 for ; Mon, 22 Jan 2007 00:43:42 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 376DC13C45D for ; Mon, 22 Jan 2007 00:43:42 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so329426nfc for ; Sun, 21 Jan 2007 16:43:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PqcR4B4FzpPLNRKxmnUD+ioIWX5Vpb9Z38LfH0CpUPRXEcYamsiT1ZzXaYogDBf136x+7rbasLXs2ZLD8LL82tNRfqH988j5CPDbatUASS8iiyY35NQ4qz2RFndfUfNQfjBAM2cAh/1mqMEpJl4tSMtq3kSFNZCMk53FxIgr300= Received: by 10.82.172.15 with SMTP id u15mr1570964bue.1169426620536; Sun, 21 Jan 2007 16:43:40 -0800 (PST) Received: by 10.82.186.2 with HTTP; Sun, 21 Jan 2007 16:43:40 -0800 (PST) Message-ID: <790a9fff0701211643x51c50dd4tdc85671824481fee@mail.gmail.com> Date: Sun, 21 Jan 2007 18:43:40 -0600 From: "Scot Hetzel" To: "Divacky Roman" In-Reply-To: <20070121222056.GA7798@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070121222056.GA7798@stud.fit.vutbr.cz> Cc: emulation@freebsd.org Subject: Re: amd64-tls: a wild idea to test 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: Mon, 22 Jan 2007 00:43:42 -0000 On 1/21/07, Divacky Roman wrote: > hi.. > > can you try this patch? its very wild idea but miracles happen :) > tls_test still coredumps on the second test. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 08:18:12 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34CD116A402; Mon, 22 Jan 2007 08:18:12 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id BDD2313C45D; Mon, 22 Jan 2007 08:18:11 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0M8IAj8043210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 09:18:10 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0M8IA9n043209; Mon, 22 Jan 2007 09:18:10 +0100 (CET) Date: Mon, 22 Jan 2007 09:18:10 +0100 From: Divacky Roman To: Tijl Coosemans Message-ID: <20070122081810.GA42976@stud.fit.vutbr.cz> References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <20070121185445.GA88090@stud.fit.vutbr.cz> <200701220001.22404.tijl@ulyssis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701220001.22404.tijl@ulyssis.org> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: freebsd-emulation@freebsd.org, jkim@freebsd.org Subject: Re: linuxolator: tls_test results amd64 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: Mon, 22 Jan 2007 08:18:12 -0000 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 From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 11:08:23 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7211016A410 for ; Mon, 22 Jan 2007 11:08:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 60A5A13C45E for ; Mon, 22 Jan 2007 11:08:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0MB8NJH036894 for ; Mon, 22 Jan 2007 11:08:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0MB8KWj036890 for freebsd-emulation@FreeBSD.org; Mon, 22 Jan 2007 11:08:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Jan 2007 11:08:20 GMT Message-Id: <200701221108.l0MB8KWj036890@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 22 Jan 2007 11:08:23 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/77710 emulation [linux] Linux page fault sigcontext information is wro o kern/101453 emulation [linux] [patch] linprocfs disallows non-zero file offs f ports/102474 emulation linux_base-fc-4_8 appears broken, does not allow to ru o kern/102956 emulation [linux] [patch] Add partial support for SO_PEERCRED in 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] feature request: easier wine/w23 support o kern/55835 emulation [linux] [patch] Linux IPC emulation missing SETALL sys a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula 8 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 14:49:57 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1989616A400 for ; Mon, 22 Jan 2007 14:49:57 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (dev.null.cz [193.85.228.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9930D13C428 for ; Mon, 22 Jan 2007 14:49:56 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (localhost [127.0.0.1]) by dev.null.cz (8.13.1/8.13.1) with ESMTP id l0MEE1TR084785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jan 2007 15:14:06 +0100 (CET) (envelope-from buki@dev.null.cz) Received: (from buki@localhost) by dev.null.cz (8.13.1/8.13.1/Submit) id l0MEE1jP084784 for emulation@freebsd.org; Mon, 22 Jan 2007 15:14:01 +0100 (CET) (envelope-from buki) Date: Mon, 22 Jan 2007 15:14:01 +0100 From: Buki To: emulation@freebsd.org Message-ID: <20070122141401.GX87089@dev.null.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5KxTQ9fdN6Op3ksq" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV 0.88.7/2476/Sun Jan 21 17:22:33 2007 on dev.null.cz X-Virus-Status: Clean Cc: Subject: linux 2.6.16 app (Skype) crash 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: Mon, 22 Jan 2007 14:49:57 -0000 --5KxTQ9fdN6Op3ksq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, following your request in -current mailing list I tried running linux appli= cation (Skype) with compat.linux.osrelease set to 2.6.16: |15:00:50|buki@hal9000:/home/buki>sudo sysctl compat.linux.osrelease=3D2.6.= 16 compat.linux.osrelease: 2.4.2 -> 2.6.16 |15:00:58|buki@hal9000:/home/buki>skype Segmentation fault (core dumped) |15:01:06|buki@hal9000:/home/buki>sudo sysctl compat.linux.osrelease=3D2.4.2 compat.linux.osrelease: 2.6.16 -> 2.4.2 |15:01:20|buki@hal9000:/home/buki>skype |15:01:55|buki@hal9000:/home/buki> (ie. normal exit) |15:01:55|buki@hal9000:/home/buki>uname -srm FreeBSD 6.2-RELEASE i386 kernel config is available at http://dev.null.cz/~buki/NTB /var/log/messages says: Jan 22 15:00:58 hal9000 sudo: buki : TTY=3Dttyp1 ; PWD=3D/usr/home/buki= ; USER=3Droot ; COMMAND=3D/sbin/sysctl compat.linux.osrelease=3D2.6.16 Jan 22 15:01:05 hal9000 kernel: Warning: pid 1719 used static ldt allocatio= n. Jan 22 15:01:05 hal9000 kernel: See the i386_set_ldt man page for more info Jan 22 15:01:06 hal9000 kernel: pid 1719 (skype_bin), uid 1001: exited on s= ignal 11 (core dumped) Jan 22 15:01:06 hal9000 kernel: pid 1721 (skype_bin), uid 1001: exited on s= ignal 11 (core dumped) Jan 22 15:01:20 hal9000 sudo: buki : TTY=3Dttyp1 ; PWD=3D/usr/home/buki= ; USER=3Droot ; COMMAND=3D/sbin/sysctl compat.linux.osrelease=3D2.4.2 The core is available at http://dev.null.cz/~buki/skype_bin.core (it has al= most 20MB) Installed packages: |15:10:52|buki@hal9000:/home/buki>pkg_info | egrep "linux|skype" linux-atk-1.9.1 Accessibility Toolkit, Linux/i386 binary linux-expat-1.95.8 Linux/i386 binary port of Expat XML-parsing library linux-fontconfig-2.2.3_5 Linux/i386 binary of Fontconfig linux-glib2-2.6.6 Version 2.X Linux/i386 binary port of GLib linux-gtk2-2.6.10 GTK+ library, version 2.X, Linux binary linux-jpeg-6b.34 RPM of the JPEG lib linux-pango-1.8.1 Linux pango binary linux-png-1.2.8_2 RPM of the PNG lib linux-realplayer-10.0.7.785.20060201 Linux RealPlayer 10 from RealNetworks linux-tiff-3.7.1 TIFF library, Linux/i386 binary linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries linux_base-fc-4_9 Base set of packages needed in Linux mode (for i386/amd= 64) linux_dri-6.5 Binary Linux DRI libraries for 3D hardware acceleration= of=20 linuxdoc-1.1_1 The Linuxdoc SGML DTD skype-1.2.0.18 P2P VoIP software Sorry for the bad news, Buki --=20 PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net --5KxTQ9fdN6Op3ksq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtMapPzhIkpLLm08RAjmbAJsFe+uatR4284W765heFn+oWQXytACff3Uv Ga7FvM/kt2yZ8aNp63rLKsE= =YTrC -----END PGP SIGNATURE----- --5KxTQ9fdN6Op3ksq-- From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 16:49:29 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60A6E16A401; Mon, 22 Jan 2007 16:49:29 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id D072113C43E; Mon, 22 Jan 2007 16:49:28 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0MGnRSv008466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 17:49:27 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0MGnQEX008465; Mon, 22 Jan 2007 17:49:26 +0100 (CET) Date: Mon, 22 Jan 2007 17:49:26 +0100 From: Divacky Roman To: current@freebsd.org Message-ID: <20070122164926.GA8146@stud.fit.vutbr.cz> References: <20070120170723.34c223fb@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070120170723.34c223fb@Magellan.Leidinger.net> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org Subject: Re: CFT/HEADS-UP: linux 2.6.16 emulation 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: Mon, 22 Jan 2007 16:49:29 -0000 On Sat, Jan 20, 2007 at 05:07:23PM +0100, Alexander Leidinger wrote: > Hi, > > today I committed the last fixes for the showstopper problems (panics) > in the linux 2.6.16 emulation. I intend to switch the default version > to 2.6.16 on i386 "soon" (see below), so please help testing it. to be more precise.. we want testing on -current on i386... any other report is useles. except for reports from p4 linuxulator branch on 2.6/amd64.. roman From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 16:52:28 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27BDC16A469; Mon, 22 Jan 2007 16:52:28 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from thumbler.kulnet.kuleuven.ac.be (thumbler.kulnet.kuleuven.ac.be [134.58.240.45]) by mx1.freebsd.org (Postfix) with ESMTP id B14A013C44C; Mon, 22 Jan 2007 16:52:27 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id A83E21382B5; Mon, 22 Jan 2007 17:52:26 +0100 (CET) Received: from smtps01 (octavianus.kulnet.kuleuven.ac.be [134.58.240.71]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id A5572137C97; Mon, 22 Jan 2007 17:52:25 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtps01 (Postfix) with ESMTP id E1CAE2E68CC; Mon, 22 Jan 2007 17:52:24 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0MGqMkc018492; Mon, 22 Jan 2007 17:52:23 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Mon, 22 Jan 2007 17:52:19 +0100 User-Agent: KMail/1.9.5 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701220001.22404.tijl@ulyssis.org> <20070122081810.GA42976@stud.fit.vutbr.cz> In-Reply-To: <20070122081810.GA42976@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701221752.21628.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: jkim@freebsd.org Subject: Re: linuxolator: tls_test results amd64 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: Mon, 22 Jan 2007 16:52:28 -0000 On Monday 22 January 2007 09:18, Divacky Roman wrote: > 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? Segment registers have a hidden part that contains base address and limit (and some more flags I guess). When you load a value into a segment register, this hidden part is updated with the info contained in the descriptor (entry in GDT/LDT). On amd64 the base address of FS and GS (in this hidden part) can also be changed directly using the wrmsr instruction. The first test requests base address 0x00000000. set_thread_area sets GS.base (in hidden part) to 0x00000000 and returns 4 as descriptor entry number. This is the user data segment descriptor, which base address is also 0x00000000 (I think). So when you next load 4<<3|3 in FS, FS.base also ends up being 0x00000000 and the test succeeds. The second test requests a different base address. GS.base is set to this address, but when you then load 4<<3|3 into FS, FS.base ends up with 0x00000000 and so your second read test fails (NULL pointer dereference). > 2) why real apps (ie. using %gs) show the very same behaviour (first > program works then it doesnt) Hmm, can you point me to the source of such a program? I would expect programs that use glibc to always fail. Glibc expects set_thread_area to setup a GDT entry and return the entry number. Then glibc loads that entry number into GS which sets up GS.base. Because of this, I would expect GS.base to always end up being 0x00000000 just as FS.base above. Wine on Linux does the same. It calls set_thread_area and loads the returned entry number in FS. (On Windows, FS is used for tls.) The reason setting GS.base directly with a wrmsr works on FreeBSD is because i386 user land code doesn't write to GS. i386_set_gsbase already sets up GS on i386, so the compatibility code on amd64 can use the wrmsr trick and leave GS itself and the descriptor it points to untouched. As far as I understand things, this won't work for linux32 compatibility on amd64. From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 17:45:38 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5127E16A402 for ; Mon, 22 Jan 2007 17:45:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 0C95013C44B for ; Mon, 22 Jan 2007 17:45:37 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0MHjapf055932 for ; Mon, 22 Jan 2007 12:45:37 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-emulation@FreeBSD.org Date: Mon, 22 Jan 2007 12:45:26 -0500 User-Agent: KMail/1.6.2 References: <200701191851.08685.jkim@FreeBSD.org> <200701200205.41517.jkim@FreeBSD.org> In-Reply-To: <200701200205.41517.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200701221245.29294.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2477/Mon Jan 22 10:10:05 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: Re: A new mmap finger printer 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: Mon, 22 Jan 2007 17:45:38 -0000 On Saturday 20 January 2007 02:05 am, Jung-uk Kim wrote: > On Friday 19 January 2007 06:51 pm, Jung-uk Kim wrote: > > I added PROT_EXEC test and cleaned up Marcin Cieslak's mmap > > finger printer. Can any one try this on a real Linux/i386 box > > and send me the output? > > http://people.freebsd.org/~jkim/mmap_test.c I realized each distro has different mmap behavior. :-( The following is the list of quirks that I found: 1. READ implies EXEC on some distros. 2. EXEC implies READ on some distros. 3. WRITE implies READ on some distros. 4. WRITE implies EXEC on some distros. Obviously we want maximum compatibility. So, I think we have to do all of the above. Actually I found that's what Linux/ia64 does for ia32 emulation. ;-) Thank you all for the reports! Jung-uk Kim From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 18:19:29 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D03A16A402 for ; Mon, 22 Jan 2007 18:19:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 0C33A13C480 for ; Mon, 22 Jan 2007 18:19:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5EE67.dip.t-dialin.net [84.165.238.103]) by redbull.bpaserver.net (Postfix) with ESMTP id 044D42E1AF; Mon, 22 Jan 2007 19:28:27 +0100 (CET) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 69FB55B4873; Mon, 22 Jan 2007 19:19:22 +0100 (CET) Date: Mon, 22 Jan 2007 19:19:22 +0100 From: Alexander Leidinger To: Buki Message-ID: <20070122191922.6d8d453a@Magellan.Leidinger.net> In-Reply-To: <20070122141401.GX87089@dev.null.cz> References: <20070122141401.GX87089@dev.null.cz> X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.8; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: emulation@freebsd.org Subject: Re: linux 2.6.16 app (Skype) crash 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: Mon, 22 Jan 2007 18:19:29 -0000 Quoting Buki (Mon, 22 Jan 2007 15:14:01 +0100): > Hi, > > following your request in -current mailing list I tried running linux application ^^^^^^^^ -current is ... > (Skype) with compat.linux.osrelease set to 2.6.16: > > |15:00:50|buki@hal9000:/home/buki>sudo sysctl compat.linux.osrelease=2.6.16 > compat.linux.osrelease: 2.4.2 -> 2.6.16 > |15:00:58|buki@hal9000:/home/buki>skype > Segmentation fault (core dumped) > |15:01:55|buki@hal9000:/home/buki>uname -srm > FreeBSD 6.2-RELEASE i386 ^^^ ... not -stable. So this is expected behavior (you are running the wrong FreeBSD version for this test). Bye, Alexander. -- BOFH excuse #425: stop bit received http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 21:26:27 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35F5416A484; Mon, 22 Jan 2007 21:26:27 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id BD21313C43E; Mon, 22 Jan 2007 21:26:26 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0MLQPZF051666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 22:26:25 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0MLQO9o051665; Mon, 22 Jan 2007 22:26:24 +0100 (CET) Date: Mon, 22 Jan 2007 22:26:24 +0100 From: Divacky Roman To: Tijl Coosemans Message-ID: <20070122212624.GA49466@stud.fit.vutbr.cz> References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701220001.22404.tijl@ulyssis.org> <20070122081810.GA42976@stud.fit.vutbr.cz> <200701221752.21628.tijl@ulyssis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701221752.21628.tijl@ulyssis.org> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: freebsd-emulation@freebsd.org, jkim@freebsd.org Subject: Re: linuxolator: tls_test results amd64 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: Mon, 22 Jan 2007 21:26:27 -0000 > > 1) why the first test succeeds? > > Segment registers have a hidden part that contains base address and > limit (and some more flags I guess). When you load a value into a > segment register, this hidden part is updated with the info contained > in the descriptor (entry in GDT/LDT). On amd64 the base address of FS > and GS (in this hidden part) can also be changed directly using the > wrmsr instruction. > > The first test requests base address 0x00000000. set_thread_area > sets GS.base (in hidden part) to 0x00000000 and returns 4 as descriptor > entry number. This is the user data segment descriptor, which base > address is also 0x00000000 (I think). So when you next load 4<<3|3 in > FS, FS.base also ends up being 0x00000000 and the test succeeds. > > The second test requests a different base address. GS.base is set to > this address, but when you then load 4<<3|3 into FS, FS.base ends up > with 0x00000000 and so your second read test fails (NULL pointer > dereference). understood > > 2) why real apps (ie. using %gs) show the very same behaviour (first > > program works then it doesnt) > > Hmm, can you point me to the source of such a program? I would expect > programs that use glibc to always fail. Glibc expects set_thread_area > to setup a GDT entry and return the entry number. Then glibc loads > that entry number into GS which sets up GS.base. Because of this, I > would expect GS.base to always end up being 0x00000000 just as FS.base > above. > > Wine on Linux does the same. It calls set_thread_area and loads the > returned entry number in FS. (On Windows, FS is used for tls.) > > The reason setting GS.base directly with a wrmsr works on FreeBSD is > because i386 user land code doesn't write to GS. i386_set_gsbase what do you mean by "writing to GS" ? > already sets up GS on i386, so the compatibility code on amd64 can > use the wrmsr trick and leave GS itself and the descriptor it points > to untouched. As far as I understand things, this won't work for > linux32 compatibility on amd64. lookin at the code it looks like: i386_set_gsbase = sysarch(I386_SET_GSBASE, &addr); and sysarch for that looks like: wrmsr(MSR_KGSBASE, i386base); pcb->pcb_gsbase = i386base; where is the setting up of the GS? I dont get it... overall you are saying that to support linux32 tls we have to 1) load an unused segment with proper values 2) return the number of the segment from the set_thread_syscall 3) make the automatic loading/unloading of that segment to happen on every context switch (just like its done for segment 3 on i386) do I get it right? anyway thnx for the explanation you finally shed some light to it. roman From owner-freebsd-emulation@FreeBSD.ORG Mon Jan 22 22:11:59 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46D4616A402; Mon, 22 Jan 2007 22:11:59 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id C159513C4A7; Mon, 22 Jan 2007 22:11:58 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0MMBvUj057974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 23:11:57 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0MMBvBI057973; Mon, 22 Jan 2007 23:11:57 +0100 (CET) Date: Mon, 22 Jan 2007 23:11:57 +0100 From: Divacky Roman To: Tijl Coosemans Message-ID: <20070122221157.GA54796@stud.fit.vutbr.cz> References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701220001.22404.tijl@ulyssis.org> <20070122081810.GA42976@stud.fit.vutbr.cz> <200701221752.21628.tijl@ulyssis.org> <20070122212624.GA49466@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070122212624.GA49466@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: freebsd-emulation@freebsd.org, jkim@freebsd.org Subject: Re: linuxolator: tls_test results amd64 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: Mon, 22 Jan 2007 22:11:59 -0000 > overall you are saying that to support linux32 tls we have to > > 1) load an unused segment with proper values > 2) return the number of the segment from the set_thread_syscall > 3) make the automatic loading/unloading of that segment to happen on > every context switch (just like its done for segment 3 on i386) rethought it a little and I think I understand now... I think simple reloading the segment thats used for TLS (which one is it?) on fbsd@amd64 should do the trick. what do you think? so instead of rewriting just the base address we reload the whole segment. that should not be that hard. but I dont understand the connection between fs/gs and the segment. is it that reloading fs_base resets the base in the segment the fs points at? roman From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 00:01:55 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FC8B16A400; Tue, 23 Jan 2007 00:01:55 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from nibbel.kulnet.kuleuven.ac.be (nibbel.kulnet.kuleuven.ac.be [134.58.240.41]) by mx1.freebsd.org (Postfix) with ESMTP id 15C3713C469; Tue, 23 Jan 2007 00:01:54 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id A6C304D2C9; Tue, 23 Jan 2007 01:01:53 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 027D74D0A6; Tue, 23 Jan 2007 01:01:53 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id B158E2CAA72; Tue, 23 Jan 2007 01:01:52 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0N01q6h042164; Tue, 23 Jan 2007 01:01:52 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Tue, 23 Jan 2007 01:01:49 +0100 User-Agent: KMail/1.9.5 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701221752.21628.tijl@ulyssis.org> <20070122212624.GA49466@stud.fit.vutbr.cz> In-Reply-To: <20070122212624.GA49466@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701230101.51580.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: jkim@freebsd.org Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 00:01:55 -0000 On Monday 22 January 2007 22:26, Divacky Roman wrote: > > > 2) why real apps (ie. using %gs) show the very same behaviour (first > > > program works then it doesnt) > > > > Hmm, can you point me to the source of such a program? I would expect > > programs that use glibc to always fail. Glibc expects set_thread_area > > to setup a GDT entry and return the entry number. Then glibc loads > > that entry number into GS which sets up GS.base. Because of this, I > > would expect GS.base to always end up being 0x00000000 just as FS.base > > above. > > > > Wine on Linux does the same. It calls set_thread_area and loads the > > returned entry number in FS. (On Windows, FS is used for tls.) > > > > The reason setting GS.base directly with a wrmsr works on FreeBSD is > > because i386 user land code doesn't write to GS. i386_set_gsbase > > what do you mean by "writing to GS" ? mov something, %gs Linux glibc does this after calling set_thread_area, which loads the base address in the GDT entry into GS.base, overwriting the GS.base previously setup using wrmsr. FreeBSD libc/libpthread don't do this. > > already sets up GS on i386, so the compatibility code on amd64 can > > use the wrmsr trick and leave GS itself and the descriptor it points > > to untouched. As far as I understand things, this won't work for > > linux32 compatibility on amd64. > > lookin at the code it looks like: > > i386_set_gsbase = sysarch(I386_SET_GSBASE, &addr); > > and sysarch for that looks like: > wrmsr(MSR_KGSBASE, i386base); > pcb->pcb_gsbase = i386base; > > where is the setting up of the GS? I dont get it... GS.base is what matters for address calculations. In the i386 version, this is set by setting up a GDT entry and loading the entry's index into GS. In the amd64 version, which you gave above, GS.base is set directly. (Actuallyn the code above sets a copy of GS.base. When switching between user and kernel mode, a swapgs instruction swaps kernel GS.base and user GS.base) > overall you are saying that to support linux32 tls we have to > > 1) load an unused segment with proper values > 2) return the number of the segment from the set_thread_syscall > 3) make the automatic loading/unloading of that segment to happen on > every context switch (just like its done for segment 3 on i386) > > do I get it right? 1) Yes, but the amd64 code has no GDT entry reserved for this right now it seems, so you have to add one. I don't really know how that's done, but what I would try (if I had the time) is to add an entry to the gdt_segs array in sys/amd64/amd64/machdep.c, say at index 6 and then adjust the defines and NGDT in sys/amd64/include/segments.h. 2) Just as you do now. Set the entry number and do a copyout. The syscall returns 0 on success. FYI, the glibc code that uses this syscall is in glibc-2.3.6/nptl/sysdeps/i386/tls.h:185:TLS_INIT_TP 3) Yes. You'll have to add a field to the pcb to store a copy of the descriptor. And then adjust the context switch code. After that, the amd64 version of set_thread_area becomes virtually the same as the i386 version. Setup a descriptor and copy it to the pcb and GDT. Most of this is copy/paste work I guess. The tricky part is to figure out what to copy and where to paste it. This should get basic tls working I think. The actual set_thread_area is a bit more complicated. It has 3 GDT entries available and when called with -1 as the entry number, it will select an unused entry. I don't know if there are programs that use all 3 (some tests maybe?). The only program I know that uses 2 is wine. From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 19:00:56 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05DBC16A400 for ; Tue, 23 Jan 2007 19:00:56 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7C11313C45B for ; Tue, 23 Jan 2007 19:00:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0NJ0nQj019454; Tue, 23 Jan 2007 14:00:53 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Tijl Coosemans Date: Tue, 23 Jan 2007 14:00:45 -0500 User-Agent: KMail/1.6.2 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <20070122212624.GA49466@stud.fit.vutbr.cz> <200701230101.51580.tijl@ulyssis.org> In-Reply-To: <200701230101.51580.tijl@ulyssis.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701231400.46367.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2480/Tue Jan 23 06:21:51 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-emulation@FreeBSD.org Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 19:00:56 -0000 On Monday 22 January 2007 07:01 pm, Tijl Coosemans wrote: > On Monday 22 January 2007 22:26, Divacky Roman wrote: > > > > 2) why real apps (ie. using %gs) show the very same behaviour > > > > (first program works then it doesnt) > > > > > > Hmm, can you point me to the source of such a program? I would > > > expect programs that use glibc to always fail. Glibc expects > > > set_thread_area to setup a GDT entry and return the entry > > > number. Then glibc loads that entry number into GS which sets > > > up GS.base. Because of this, I would expect GS.base to always > > > end up being 0x00000000 just as FS.base above. > > > > > > Wine on Linux does the same. It calls set_thread_area and loads > > > the returned entry number in FS. (On Windows, FS is used for > > > tls.) > > > > > > The reason setting GS.base directly with a wrmsr works on > > > FreeBSD is because i386 user land code doesn't write to GS. > > > i386_set_gsbase > > > > what do you mean by "writing to GS" ? > > mov something, %gs > > Linux glibc does this after calling set_thread_area, which loads > the base address in the GDT entry into GS.base, overwriting the > GS.base previously setup using wrmsr. FreeBSD libc/libpthread don't > do this. > > > > already sets up GS on i386, so the compatibility code on amd64 > > > can use the wrmsr trick and leave GS itself and the descriptor > > > it points to untouched. As far as I understand things, this > > > won't work for linux32 compatibility on amd64. > > > > lookin at the code it looks like: > > > > i386_set_gsbase = sysarch(I386_SET_GSBASE, &addr); > > > > and sysarch for that looks like: > > wrmsr(MSR_KGSBASE, i386base); > > pcb->pcb_gsbase = i386base; > > > > where is the setting up of the GS? I dont get it... > > GS.base is what matters for address calculations. In the i386 > version, this is set by setting up a GDT entry and loading the > entry's index into GS. In the amd64 version, which you gave above, > GS.base is set directly. > (Actuallyn the code above sets a copy of GS.base. When switching > between user and kernel mode, a swapgs instruction swaps kernel > GS.base and user GS.base) > > > overall you are saying that to support linux32 tls we have to > > > > 1) load an unused segment with proper values > > 2) return the number of the segment from the set_thread_syscall > > 3) make the automatic loading/unloading of that segment to happen > > on every context switch (just like its done for segment 3 on > > i386) > > > > do I get it right? > > 1) Yes, but the amd64 code has no GDT entry reserved for this right > now it seems, so you have to add one. I don't really know how > that's done, but what I would try (if I had the time) is to add an > entry to the gdt_segs array in sys/amd64/amd64/machdep.c, say at > index 6 and then adjust the defines and NGDT in > sys/amd64/include/segments.h. > > 2) Just as you do now. Set the entry number and do a copyout. The > syscall returns 0 on success. FYI, the glibc code that uses this > syscall is in glibc-2.3.6/nptl/sysdeps/i386/tls.h:185:TLS_INIT_TP > > 3) Yes. You'll have to add a field to the pcb to store a copy of > the descriptor. And then adjust the context switch code. > > After that, the amd64 version of set_thread_area becomes virtually > the same as the i386 version. Setup a descriptor and copy it to the > pcb and GDT. > > Most of this is copy/paste work I guess. The tricky part is to > figure out what to copy and where to paste it. > > > This should get basic tls working I think. The actual > set_thread_area is a bit more complicated. It has 3 GDT entries > available and when called with -1 as the entry number, it will > select an unused entry. I don't know if there are programs that use > all 3 (some tests maybe?). The only program I know that uses 2 is > wine. I was little quiet yesterday because I wasn't sure. But I have more evidence now. First of all, wrmsr(MSR_KGSBASE, ...) must be protected with 'if (td == curthread)' just as cpu_set_user_tls() does, which is very trivial. Second problem is MSR_KGSBASE is scrubbed by something during context switch, i.e., it becomes 0 some times. I was not able to pin point where it happens yet, though. When it does not happen, i.e., pcb->pcb_gsbase == rdmsr(MSR_KGSBASE), static binaries run okay. Dynamic binary issue seems to be more complicated but I believe we can do this without implementing whole TLS segment like Linux does. FYI... Jung-uk Kim From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 20:14:01 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A967716A402; Tue, 23 Jan 2007 20:14:01 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from rusty.kulnet.kuleuven.ac.be (rusty.kulnet.kuleuven.ac.be [134.58.240.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3F51513C4D3; Tue, 23 Jan 2007 20:14:01 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id CC9C01D7814; Tue, 23 Jan 2007 21:13:59 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id D09011D775B; Tue, 23 Jan 2007 21:13:58 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id EF0882CA9C8; Tue, 23 Jan 2007 21:13:54 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0NKDpJg008225; Tue, 23 Jan 2007 21:13:52 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Tue, 23 Jan 2007 21:13:48 +0100 User-Agent: KMail/1.9.5 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701230101.51580.tijl@ulyssis.org> <200701231400.46367.jkim@FreeBSD.org> In-Reply-To: <200701231400.46367.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701232113.50766.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: Jung-uk Kim Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 20:14:01 -0000 On Tuesday 23 January 2007 20:00, Jung-uk Kim wrote: > On Monday 22 January 2007 07:01 pm, Tijl Coosemans wrote: > > On Monday 22 January 2007 22:26, Divacky Roman wrote: > > > > > 2) why real apps (ie. using %gs) show the very same behaviour > > > > > (first program works then it doesnt) > > > > > > > > Hmm, can you point me to the source of such a program? I would > > > > expect programs that use glibc to always fail. Glibc expects > > > > set_thread_area to setup a GDT entry and return the entry > > > > number. Then glibc loads that entry number into GS which sets > > > > up GS.base. Because of this, I would expect GS.base to always > > > > end up being 0x00000000 just as FS.base above. > > > > > > > > Wine on Linux does the same. It calls set_thread_area and loads > > > > the returned entry number in FS. (On Windows, FS is used for > > > > tls.) > > > > > > > > The reason setting GS.base directly with a wrmsr works on > > > > FreeBSD is because i386 user land code doesn't write to GS. > > > > i386_set_gsbase > > > > > > what do you mean by "writing to GS" ? > > > > mov something, %gs > > > > Linux glibc does this after calling set_thread_area, which loads > > the base address in the GDT entry into GS.base, overwriting the > > GS.base previously setup using wrmsr. FreeBSD libc/libpthread don't > > do this. > > > > > > already sets up GS on i386, so the compatibility code on amd64 > > > > can use the wrmsr trick and leave GS itself and the descriptor > > > > it points to untouched. As far as I understand things, this > > > > won't work for linux32 compatibility on amd64. > > > > > > lookin at the code it looks like: > > > > > > i386_set_gsbase = sysarch(I386_SET_GSBASE, &addr); > > > > > > and sysarch for that looks like: > > > wrmsr(MSR_KGSBASE, i386base); > > > pcb->pcb_gsbase = i386base; > > > > > > where is the setting up of the GS? I dont get it... > > > > GS.base is what matters for address calculations. In the i386 > > version, this is set by setting up a GDT entry and loading the > > entry's index into GS. In the amd64 version, which you gave above, > > GS.base is set directly. > > (Actuallyn the code above sets a copy of GS.base. When switching > > between user and kernel mode, a swapgs instruction swaps kernel > > GS.base and user GS.base) > > > > > overall you are saying that to support linux32 tls we have to > > > > > > 1) load an unused segment with proper values > > > 2) return the number of the segment from the set_thread_syscall > > > 3) make the automatic loading/unloading of that segment to happen > > > on every context switch (just like its done for segment 3 on > > > i386) > > > > > > do I get it right? > > > > 1) Yes, but the amd64 code has no GDT entry reserved for this right > > now it seems, so you have to add one. I don't really know how > > that's done, but what I would try (if I had the time) is to add an > > entry to the gdt_segs array in sys/amd64/amd64/machdep.c, say at > > index 6 and then adjust the defines and NGDT in > > sys/amd64/include/segments.h. > > > > 2) Just as you do now. Set the entry number and do a copyout. The > > syscall returns 0 on success. FYI, the glibc code that uses this > > syscall is in glibc-2.3.6/nptl/sysdeps/i386/tls.h:185:TLS_INIT_TP > > > > 3) Yes. You'll have to add a field to the pcb to store a copy of > > the descriptor. And then adjust the context switch code. > > > > After that, the amd64 version of set_thread_area becomes virtually > > the same as the i386 version. Setup a descriptor and copy it to the > > pcb and GDT. > > > > Most of this is copy/paste work I guess. The tricky part is to > > figure out what to copy and where to paste it. > > > > > > This should get basic tls working I think. The actual > > set_thread_area is a bit more complicated. It has 3 GDT entries > > available and when called with -1 as the entry number, it will > > select an unused entry. I don't know if there are programs that use > > all 3 (some tests maybe?). The only program I know that uses 2 is > > wine. > > I was little quiet yesterday because I wasn't sure. But I have more > evidence now. First of all, wrmsr(MSR_KGSBASE, ...) must be > protected with 'if (td == curthread)' just as cpu_set_user_tls() > does, which is very trivial. Second problem is MSR_KGSBASE is > scrubbed by something during context switch, i.e., it becomes 0 some > times. You mean: *kernel sets gsbase and switches back to user mode *user program does things *back in kernel mode, save gsbase into pcb and it appears to be 0 now? From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 20:56:01 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7CAC16A400 for ; Tue, 23 Jan 2007 20:56:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7E613C4D5 for ; Tue, 23 Jan 2007 20:56:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0NKu0YW026734; Tue, 23 Jan 2007 15:56:00 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Tijl Coosemans Date: Tue, 23 Jan 2007 15:55:54 -0500 User-Agent: KMail/1.6.2 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701231400.46367.jkim@FreeBSD.org> <200701232113.50766.tijl@ulyssis.org> In-Reply-To: <200701232113.50766.tijl@ulyssis.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701231555.57521.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2480/Tue Jan 23 06:21:51 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-emulation@FreeBSD.org Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 20:56:01 -0000 On Tuesday 23 January 2007 03:13 pm, Tijl Coosemans wrote: > On Tuesday 23 January 2007 20:00, Jung-uk Kim wrote: > > On Monday 22 January 2007 07:01 pm, Tijl Coosemans wrote: > > > On Monday 22 January 2007 22:26, Divacky Roman wrote: > > > > > > 2) why real apps (ie. using %gs) show the very same > > > > > > behaviour (first program works then it doesnt) > > > > > > > > > > Hmm, can you point me to the source of such a program? I > > > > > would expect programs that use glibc to always fail. Glibc > > > > > expects set_thread_area to setup a GDT entry and return the > > > > > entry number. Then glibc loads that entry number into GS > > > > > which sets up GS.base. Because of this, I would expect > > > > > GS.base to always end up being 0x00000000 just as FS.base > > > > > above. > > > > > > > > > > Wine on Linux does the same. It calls set_thread_area and > > > > > loads the returned entry number in FS. (On Windows, FS is > > > > > used for tls.) > > > > > > > > > > The reason setting GS.base directly with a wrmsr works on > > > > > FreeBSD is because i386 user land code doesn't write to GS. > > > > > i386_set_gsbase > > > > > > > > what do you mean by "writing to GS" ? > > > > > > mov something, %gs > > > > > > Linux glibc does this after calling set_thread_area, which > > > loads the base address in the GDT entry into GS.base, > > > overwriting the GS.base previously setup using wrmsr. FreeBSD > > > libc/libpthread don't do this. > > > > > > > > already sets up GS on i386, so the compatibility code on > > > > > amd64 can use the wrmsr trick and leave GS itself and the > > > > > descriptor it points to untouched. As far as I understand > > > > > things, this won't work for linux32 compatibility on amd64. > > > > > > > > lookin at the code it looks like: > > > > > > > > i386_set_gsbase = sysarch(I386_SET_GSBASE, &addr); > > > > > > > > and sysarch for that looks like: > > > > wrmsr(MSR_KGSBASE, i386base); > > > > pcb->pcb_gsbase = i386base; > > > > > > > > where is the setting up of the GS? I dont get it... > > > > > > GS.base is what matters for address calculations. In the i386 > > > version, this is set by setting up a GDT entry and loading the > > > entry's index into GS. In the amd64 version, which you gave > > > above, GS.base is set directly. > > > (Actuallyn the code above sets a copy of GS.base. When > > > switching between user and kernel mode, a swapgs instruction > > > swaps kernel GS.base and user GS.base) > > > > > > > overall you are saying that to support linux32 tls we have to > > > > > > > > 1) load an unused segment with proper values > > > > 2) return the number of the segment from the > > > > set_thread_syscall 3) make the automatic loading/unloading of > > > > that segment to happen on every context switch (just like its > > > > done for segment 3 on i386) > > > > > > > > do I get it right? > > > > > > 1) Yes, but the amd64 code has no GDT entry reserved for this > > > right now it seems, so you have to add one. I don't really know > > > how that's done, but what I would try (if I had the time) is to > > > add an entry to the gdt_segs array in > > > sys/amd64/amd64/machdep.c, say at index 6 and then adjust the > > > defines and NGDT in > > > sys/amd64/include/segments.h. > > > > > > 2) Just as you do now. Set the entry number and do a copyout. > > > The syscall returns 0 on success. FYI, the glibc code that uses > > > this syscall is in > > > glibc-2.3.6/nptl/sysdeps/i386/tls.h:185:TLS_INIT_TP > > > > > > 3) Yes. You'll have to add a field to the pcb to store a copy > > > of the descriptor. And then adjust the context switch code. > > > > > > After that, the amd64 version of set_thread_area becomes > > > virtually the same as the i386 version. Setup a descriptor and > > > copy it to the pcb and GDT. > > > > > > Most of this is copy/paste work I guess. The tricky part is to > > > figure out what to copy and where to paste it. > > > > > > > > > This should get basic tls working I think. The actual > > > set_thread_area is a bit more complicated. It has 3 GDT entries > > > available and when called with -1 as the entry number, it will > > > select an unused entry. I don't know if there are programs that > > > use all 3 (some tests maybe?). The only program I know that > > > uses 2 is wine. > > > > I was little quiet yesterday because I wasn't sure. But I have > > more evidence now. First of all, wrmsr(MSR_KGSBASE, ...) must be > > protected with 'if (td == curthread)' just as cpu_set_user_tls() > > does, which is very trivial. Second problem is MSR_KGSBASE is > > scrubbed by something during context switch, i.e., it becomes 0 > > some times. > > You mean: > > *kernel sets gsbase and switches back to user mode > *user program does things Yes. BTW, glibc seems to use movw instead of movl to load %gs. I don't know if that makes difference, though. It may have some effect when glibc is built with -mtls-direct-seg-refs flag. Need confirmation. > *back in kernel mode, save gsbase into pcb and it appears to be 0 > now? 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?). Jung-uk Kim From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 21:24:38 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEEE416A403; Tue, 23 Jan 2007 21:24:38 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 86AF013C468; Tue, 23 Jan 2007 21:24:38 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0NLOaLD023997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 22:24:36 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0NLOasC023994; Tue, 23 Jan 2007 22:24:36 +0100 (CET) Date: Tue, 23 Jan 2007 22:24:36 +0100 From: Divacky Roman To: Jung-uk Kim Message-ID: <20070123212436.GA23722@stud.fit.vutbr.cz> References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <20070122212624.GA49466@stud.fit.vutbr.cz> <200701230101.51580.tijl@ulyssis.org> <200701231400.46367.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701231400.46367.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: freebsd-emulation@FreeBSD.org Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 21:24:39 -0000 > I was little quiet yesterday because I wasn't sure. But I have more > evidence now. First of all, wrmsr(MSR_KGSBASE, ...) must be > protected with 'if (td == curthread)' just as cpu_set_user_tls() this is not true... in set_thread_area td is curthread all the time and in clone its never true... so the condition becomes constant. (i386 is exactly the same case) feel free to prove me wrong :) From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 22:43:55 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A61B16A402; Tue, 23 Jan 2007 22:43:55 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from rusty.kulnet.kuleuven.ac.be (rusty.kulnet.kuleuven.ac.be [134.58.240.42]) by mx1.freebsd.org (Postfix) with ESMTP id A7E7D13C455; Tue, 23 Jan 2007 22:43:54 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 7AC1B1D7491; Tue, 23 Jan 2007 23:43:53 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 43AB11D7950; Tue, 23 Jan 2007 23:43:52 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id 187442CA9C8; Tue, 23 Jan 2007 23:43:49 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0NMhmlB009780; Tue, 23 Jan 2007 23:43:48 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Tue, 23 Jan 2007 23:43:45 +0100 User-Agent: KMail/1.9.5 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701232113.50766.tijl@ulyssis.org> <200701231555.57521.jkim@FreeBSD.org> In-Reply-To: <200701231555.57521.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701232343.47316.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: Jung-uk Kim Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 22:43:55 -0000 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. > > > > You mean: > > > > *kernel sets gsbase and switches back to user mode > > *user program does things > > Yes. BTW, glibc seems to use movw instead of movl to load %gs. I > don't know if that makes difference, though. It may have some > effect when glibc is built with -mtls-direct-seg-refs flag. Need > confirmation. I think there's no difference between movw and movl. The first stores a 16 bit value in %gs, the second stores the lower 16 bits of a 32 bit value. That flag is interesting, but I think it only relates to using %gs after it has been set up for tls. > > *back in kernel mode, save gsbase into pcb and it appears to be 0 > > now? > > 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? From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 22:59:04 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 185DB16A401 for ; Tue, 23 Jan 2007 22:59:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA0613C43E for ; Tue, 23 Jan 2007 22:59:03 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0NMx2t6033991; Tue, 23 Jan 2007 17:59:02 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Tijl Coosemans Date: Tue, 23 Jan 2007 17:58:58 -0500 User-Agent: KMail/1.6.2 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701231555.57521.jkim@FreeBSD.org> <200701232343.47316.tijl@ulyssis.org> In-Reply-To: <200701232343.47316.tijl@ulyssis.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701231758.59489.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2480/Tue Jan 23 06:21:51 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-emulation@FreeBSD.org Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 22:59:04 -0000 On Tuesday 23 January 2007 05:43 pm, 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. > > > > > > You mean: > > > > > > *kernel sets gsbase and switches back to user mode > > > *user program does things > > > > Yes. BTW, glibc seems to use movw instead of movl to load %gs. > > I don't know if that makes difference, though. It may have some > > effect when glibc is built with -mtls-direct-seg-refs flag. Need > > confirmation. > > I think there's no difference between movw and movl. The first > stores a 16 bit value in %gs, the second stores the lower 16 bits > of a 32 bit value. > > That flag is interesting, but I think it only relates to using %gs > after it has been set up for tls. > > > > *back in kernel mode, save gsbase into pcb and it appears to be > > > 0 now? > > > > 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? I believe it was part of peter and davidxu's micro optimizations, though. I was experimenting with the cpu_switch.S but it might be hard to correct it without reverting the optimizations. :-( We can probably add another pcb_flag? Jung-uk Kim From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 22:59:11 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F9FB16A401; Tue, 23 Jan 2007 22:59:11 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from thumbler.kulnet.kuleuven.ac.be (thumbler.kulnet.kuleuven.ac.be [134.58.240.45]) by mx1.freebsd.org (Postfix) with ESMTP id 51D8513C448; Tue, 23 Jan 2007 22:59:11 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 23E79137FE4; Tue, 23 Jan 2007 23:59:10 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 41688137EF3; Tue, 23 Jan 2007 23:59:09 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id 096F42CA9C8; Tue, 23 Jan 2007 23:59:08 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0NMx7KA009976; Tue, 23 Jan 2007 23:59:08 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Tue, 23 Jan 2007 23:59:04 +0100 User-Agent: KMail/1.9.5 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701231555.57521.jkim@FreeBSD.org> <200701232343.47316.tijl@ulyssis.org> In-Reply-To: <200701232343.47316.tijl@ulyssis.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701232359.07434.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: Jung-uk Kim Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 22:59:11 -0000 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. From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 23 23:12:57 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B29916A401 for ; Tue, 23 Jan 2007 23:12:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id F000313C4BF for ; Tue, 23 Jan 2007 23:12:56 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0NNCpKO034701; Tue, 23 Jan 2007 18:12:55 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Tijl Coosemans Date: Tue, 23 Jan 2007 18:12:45 -0500 User-Agent: KMail/1.6.2 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701232343.47316.tijl@ulyssis.org> <200701232359.07434.tijl@ulyssis.org> In-Reply-To: <200701232359.07434.tijl@ulyssis.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701231812.48455.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2481/Tue Jan 23 17:10:15 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-emulation@FreeBSD.org Subject: Re: linuxolator: tls_test results amd64 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, 23 Jan 2007 23:12:57 -0000 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 From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 24 00:10:07 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3D7816A410 for ; Wed, 24 Jan 2007 00:10:06 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 70C1D13C4E1 for ; Wed, 24 Jan 2007 00:10:06 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0O0A4bw036953; Tue, 23 Jan 2007 19:10:05 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Tijl Coosemans Date: Tue, 23 Jan 2007 19:09:59 -0500 User-Agent: KMail/1.6.2 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701232359.07434.tijl@ulyssis.org> <200701231812.48455.jkim@FreeBSD.org> In-Reply-To: <200701231812.48455.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701231910.02033.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2481/Tue Jan 23 17:10:15 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-emulation@FreeBSD.org Subject: Re: linuxolator: tls_test results amd64 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: Wed, 24 Jan 2007 00:10:07 -0000 On Tuesday 23 January 2007 06:12 pm, Jung-uk Kim wrote: > 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/li >nuxthreads/sysdeps/i386/tls.h?rev=1.39&content-type=text/plain&cvsro >ot=glibc I have read through entire segment register section of AMD64 manual and I understand the whole picture now. fsbase/gsbase is not restored for 32-bit thread because it is ignored in Compatibility Mode. In Compatibility Mode, the segment regiter load is exactly like legacy x86 mode, i.e., hidden portion is not loaded from fsbase/gsbase but from GDT. So, you're right; there is no other way to implement this correctly without setting up segment descriptor. :-( Jung-uk Kim From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 24 02:01:33 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 834A216A405; Wed, 24 Jan 2007 02:01:33 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by mx1.freebsd.org (Postfix) with ESMTP id 6192213C4C2; Wed, 24 Jan 2007 02:01:33 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.176.159]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JCC002G2OA3V0UD@vms048.mailsrvcs.net>; Tue, 23 Jan 2007 20:01:16 -0600 (CST) Date: Tue, 23 Jan 2007 21:01:09 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <20070120170723.34c223fb@Magellan.Leidinger.net> To: Alexander Leidinger Message-id: <1169604069.1132.3.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <20070120170723.34c223fb@Magellan.Leidinger.net> Cc: emulation@freebsd.org, current@freebsd.org Subject: Re: CFT/HEADS-UP: linux 2.6.16 emulation 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: Wed, 24 Jan 2007 02:01:33 -0000 On Sat, 2007-01-20 at 17:07 +0100, Alexander Leidinger wrote: > Hi, > > today I committed the last fixes for the showstopper problems (panics) > in the linux 2.6.16 emulation. I intend to switch the default version > to 2.6.16 on i386 "soon" (see below), so please help testing it. > > More recent linux distributions (e.g. FC5) require a 2.6 kernel and > don't work with 2.4.2 anymore. And because FC4 is "abandon-ware" (no > security fixes from fedoralegacy anymore), getting 2.6.16 emulation up > an running is very important. > > If you use a linux program, please add compat.linux.osrelease=2.6.16 > to /etc/sysctl.conf (my desktop is running with 2.6.16 emulation since > some days already). After the next boot (or after running "sysctl > compat.linux.osrelease=2.6.16", please make sure no linux program is > running already) any linux program will start with a linux kernel > version of 2.6.16 instead of 2.4.2. The default linux base port (FC4) > will then use different code paths (e.g. within glibc). In case you > want to switch back to the 2.4.2 emulation without a reboot, please > make sure no linux program is running anymore. > > So far we fixed all known/repeatable problems with acroread, > realplayer, skype and linux firefox. If you encounter strange behavior > with any linux program, please tell us (emulation@freebsd.org) which > program you used, how to repeat the problem, what the problem is, and > if it only is visible with 2.6.16 or with 2.4.2 too. You should also > watch out for messages in the dmesg (unimplemented system calls or other > stuff, this is used to determine the priority of missing syscalls). > Please also have a look at http://wiki.FreeBSD.org/linux-kernel, I > intend to document the known problems there. If you find your problem > there, please tell us about it if you are willing to test fixes. > > We are specially interested in reports (good or bad) on SMP systems. > Please beat the hell out of the linuxulator! > > On amd64 systems we have not the same functionality as on i386, missing > are futexes and TLS. In P4 we already have the futex part covered, but > the TLS part is still missing (anyone with a clue about the kernel side > of TLS on amd64 is welcome to give a hint or two to jkim@ and > rdivacky@). So if you get a message about missing futexes or TLS on > amd64: we know about it (testers for the futex stuff are welcome, but > first you need to use a program which uses futexes and complains). > > As long as we get problem reports with 2.6.16 I will not switch the > default to 2.6.16. If we don't get a report at all, I will switch the > default on i386 to 2.6.16 in two weeks. If we get some problem reports, > we will push back the switch a little bit depending on the severity of > the problem. > > Bye, > Alexander. > With current of yesterday and compat.linux.osrelease=2.6.16 Acrobat Reader, Real Player and Firefox (including Flash plugin) seem to behave on my ThinkPad X60 (SMP machine). Admittedly use was light, but hopefully this report will encourage more people to try switching to new linuxolator. -- Alexandre "Sunny" Kovalenko From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 24 06:11:59 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE47716A403; Wed, 24 Jan 2007 06:11:58 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 811D213C44C; Wed, 24 Jan 2007 06:11:58 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 540C66E0DA; Wed, 24 Jan 2007 17:11:53 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id C33652742A; Wed, 24 Jan 2007 17:11:53 +1100 (EST) Date: Wed, 24 Jan 2007 17:11:47 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Tijl Coosemans In-Reply-To: <200701232343.47316.tijl@ulyssis.org> Message-ID: <20070124160934.V36320@delplex.bde.org> References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701232113.50766.tijl@ulyssis.org> <200701231555.57521.jkim@FreeBSD.org> <200701232343.47316.tijl@ulyssis.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-emulation@FreeBSD.org, Jung-uk Kim Subject: Re: linuxolator: tls_test results amd64 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: Wed, 24 Jan 2007 06:11:59 -0000 On Tue, 23 Jan 2007, 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. >>> >>> You mean: >>> >>> *kernel sets gsbase and switches back to user mode >>> *user program does things >> >> Yes. BTW, glibc seems to use movw instead of movl to load %gs. I >> don't know if that makes difference, though. It may have some >> effect when glibc is built with -mtls-direct-seg-refs flag. Need >> confirmation. > > I think there's no difference between movw and movl. The first stores > a 16 bit value in %gs, the second stores the lower 16 bits of a 32 bit > value. movl is a workaround for pessimizations and/or bugs in old versions of gas. Old versions of gas didn't understand operand sizes so they generated pessimal operand size prefixes and in general (for other instructions) made a mess when the source and target operands have different sizes. Gas now detects mismatched sizes but allows them in this case: %%% GAS LISTING gas.s page 1 1 0000 8EE8 movl %eax,%gs 2 0002 8EE8 mov %eax,%gs 3 0004 8EE8 movw %ax,%gs 4 0006 8EE8 mov %ax,%gs 5 6 0008 8E2D0000 movl 0,%gs 6 0000 7 000e 8E2D0000 mov 0,%gs 7 0000 8 0014 8E2D0000 movw 0,%gs 8 0000 %%% so the old workaround has no effect. When I wrote my i386 assembler, I thought that the 32-bit source value couldn't even exist for the case of move from memory. It makes a difference whether the load is a 16-bit or 32-bit one. If it is 32-bit, despite there not being an operand size prefix in 32-bit mode, then it might trap where a 16-bit load would not, because only the 32-bit load crosses a segment or page boundary. I think it is always 16-bit. Thus asking for a 32-bit move to a segment register is just bogus. My assembler enforces this: %%% ... 00001 mov dword ds,eax ***** ^mismatched size ***** ^mismatched size 00002 mov ds,eax ***** ^mismatched size 00003 0000 8ED8 mov word ds,ax 00004 0002 8ED8 mov ds,ax 00005 00006 0004 67 8E1E 0000 mov dword ds,[0] ***** ^mismatched size 00007 0009 67 8E1E 0000 mov ds,[0] 00008 000E 67 8E1E 0000 mov ds,[0] ... %%% My assembler doesn't generate an operand size prefix, but generates an address size prefix to optimize the loads from address 0 for space. This is possible because these address is known to fit in 16 bits. I don't know how to make gas do this (cc -Os doesn't give it). So if a 32-bit store is different and you actually want it, neither assembler supports it directly (you have to manually add an operand size prefix explicitly). Moves _from_ segment registers are completely different. For push of a segment register, you normally want a 32-bit access to keep the stack aligned and perhaps to avoid leaving garbage on the stack. mov of a segment register to memory is little different. Even pop of a segment is little different -- it increments the stack pointer by 4 for compatibility with push, but I think it doesn't access the upper 16 bits. IIRC, 32-bit writes of segment registers to another register or memory write CPU-dependent garbage to the top 32 bits. Newer CPUs are more likely to write 0's and older CPUs are more likely to write pure garbage. The garbage is most visible in debugger output. Gas now gets this right by determining the operand sizes correctly and generating the operand size prefix iff it is necessary. It generates the operand size prefix as necessary for popw in 32-bit mode, so the prefix is not completely unnecessary for loads -- it is necessary to do the correct stack adjustment. Gas doesn't generate any operand sizes for mov's to memory, and I think the memory access size is always 16 despite this, the same as for mov's from memoery. FreeBSD still uses movl from segment registers in most places to ensure not getting an operand size prefixes. Unnecessary operand size prefixes cost more on older CPUs. On newer CPUs they get decoded into nothing before reaching final pipeline stages. My assembler has always got this completely wrong (except probably in Linux versions that I haven't looked at), at least for push (and pop too) and for mov's to registers. It enforces a 16-bit operand size for everything. This is especially broken for push/pop in 32-bit mode. Some of the CPU behaviours (especially for movl from a segreg to a general register) seem to be only documented in newer CPU manuals. I've never seen or wrote documentation for the asm behaviours and have to write the above programs to remember what they are. Bruce From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 24 13:36:45 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47D4F16A404; Wed, 24 Jan 2007 13:36:45 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from thumbler.kulnet.kuleuven.ac.be (thumbler.kulnet.kuleuven.ac.be [134.58.240.45]) by mx1.freebsd.org (Postfix) with ESMTP id CD82E13C45B; Wed, 24 Jan 2007 13:36:44 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id CB1AE1381FA; Wed, 24 Jan 2007 14:36:43 +0100 (CET) Received: from smtps01 (octavianus.kulnet.kuleuven.ac.be [134.58.240.71]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id D0CC0138149; Wed, 24 Jan 2007 14:36:42 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtps01 (Postfix) with ESMTP id 737E42E68CA; Wed, 24 Jan 2007 14:36:42 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0ODafjA003155; Wed, 24 Jan 2007 14:36:41 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-emulation@freebsd.org Date: Wed, 24 Jan 2007 14:36:36 +0100 User-Agent: KMail/1.9.5 References: <790a9fff0701211041j1176d00gd6dd75d0989cf4ec@mail.gmail.com> <200701231812.48455.jkim@FreeBSD.org> <200701231910.02033.jkim@FreeBSD.org> In-Reply-To: <200701231910.02033.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701241436.40627.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: peter@freebsd.org, jkim@freebsd.org Subject: Re: linuxolator: tls_test results amd64 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: Wed, 24 Jan 2007 13:36:45 -0000 On Wednesday 24 January 2007 01:09, Jung-uk Kim wrote: > On Tuesday 23 January 2007 06:12 pm, Jung-uk Kim wrote: > > 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 > > I have read through entire segment register section of AMD64 manual > and I understand the whole picture now. fsbase/gsbase is not > restored for 32-bit thread because it is ignored in Compatibility > Mode. In Compatibility Mode, the segment regiter load is exactly > like legacy x86 mode, i.e., hidden portion is not loaded from > fsbase/gsbase but from GDT. So, you're right; there is no other way > to implement this correctly without setting up segment > descriptor. :-( That's not how I understood the manual. I think in the case of FS and GS, segment register load is the same in both modes (32/64). That is, in both cases the 32 bit base address in the GDT descriptor is copied to the lower 32 bits of the base address in the hidden portion of the segment register and the upper 32 bits of this address are set to 0. If you want to set the full 64 bit base address, you have to use wrmsr. The only difference between 64 bit mode and 32 bit compatibility mode in this case is that in compat mode, the upper 32 bit of this base address are ignored for address calculations. So I don't think pcb_fsbase and pcb_gsbase should be ignored when switching to a 32 bit thread as they are now. How else are i386_set_fsbase/gsbase supposed to work? From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 24 14:41:14 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2364C16A403; Wed, 24 Jan 2007 14:41:14 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id AB1A613C45A; Wed, 24 Jan 2007 14:41:13 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0OEfBCe026281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jan 2007 15:41:11 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0OEfB0d026280; Wed, 24 Jan 2007 15:41:11 +0100 (CET) Date: Wed, 24 Jan 2007 15:41:11 +0100 From: Divacky Roman To: Tijl Coosemans Message-ID: <20070124144111.GA25708@stud.fit.vutbr.cz> References: <20070120170723.34c223fb@Magellan.Leidinger.net> <1169604069.1132.3.camel@RabbitsDen.RabbitsLawn.verizon.net> <200701241526.23353.tijl@ulyssis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701241526.23353.tijl@ulyssis.org> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, Alexander Leidinger , freebsd-current@freebsd.org, Alexandre Sunny Kovalenko Subject: Re: CFT/HEADS-UP: linux 2.6.16 emulation 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: Wed, 24 Jan 2007 14:41:14 -0000 On Wed, Jan 24, 2007 at 03:26:19PM +0100, Tijl Coosemans wrote: > On Wednesday 24 January 2007 03:01, Alexandre "Sunny" Kovalenko wrote: > > With current of yesterday and compat.linux.osrelease=2.6.16 Acrobat > > Reader, Real Player and Firefox (including Flash plugin) seem to behave > > What flash version? Flash plugin 9 is still very unstable for me (2.4.2 > and 2.6.16). Any YouTube video crashes it after anywhere from 5 to 50 > seconds. same here.. but people report problems on 6.x as well so I dont think its problem of linuxulator (I might be wrong of course) From owner-freebsd-emulation@FreeBSD.ORG Wed Jan 24 14:48:54 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 578A216A400 for ; Wed, 24 Jan 2007 14:48:54 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from rusty.kulnet.kuleuven.ac.be (rusty.kulnet.kuleuven.ac.be [134.58.240.42]) by mx1.freebsd.org (Postfix) with ESMTP id 17AF713C4C9 for ; Wed, 24 Jan 2007 14:48:54 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 852ED1D7813; Wed, 24 Jan 2007 15:26:26 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 626CC1D788A; Wed, 24 Jan 2007 15:26:25 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id 2DFBC2CAA72; Wed, 24 Jan 2007 15:26:25 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l0OEQN4C003757; Wed, 24 Jan 2007 15:26:24 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-current@freebsd.org Date: Wed, 24 Jan 2007 15:26:19 +0100 User-Agent: KMail/1.9.5 References: <20070120170723.34c223fb@Magellan.Leidinger.net> <1169604069.1132.3.camel@RabbitsDen.RabbitsLawn.verizon.net> In-Reply-To: <1169604069.1132.3.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701241526.23353.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: emulation@freebsd.org, Alexander Leidinger , "Alexandre \"Sunny\" Kovalenko" Subject: Re: CFT/HEADS-UP: linux 2.6.16 emulation 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: Wed, 24 Jan 2007 14:48:54 -0000 On Wednesday 24 January 2007 03:01, Alexandre "Sunny" Kovalenko wrote: > With current of yesterday and compat.linux.osrelease=2.6.16 Acrobat > Reader, Real Player and Firefox (including Flash plugin) seem to behave What flash version? Flash plugin 9 is still very unstable for me (2.4.2 and 2.6.16). Any YouTube video crashes it after anywhere from 5 to 50 seconds. From owner-freebsd-emulation@FreeBSD.ORG Thu Jan 25 00:51:51 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDF9216A400; Thu, 25 Jan 2007 00:51:51 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.freebsd.org (Postfix) with ESMTP id B08CD13C455; Thu, 25 Jan 2007 00:51:51 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.176.159]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JCE001EOFPZ9C04@vms042.mailsrvcs.net>; Wed, 24 Jan 2007 18:51:36 -0600 (CST) Date: Wed, 24 Jan 2007 19:51:25 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <200701241526.23353.tijl@ulyssis.org> To: Tijl Coosemans Message-id: <1169686286.33062.0.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <20070120170723.34c223fb@Magellan.Leidinger.net> <1169604069.1132.3.camel@RabbitsDen.RabbitsLawn.verizon.net> <200701241526.23353.tijl@ulyssis.org> Cc: emulation@freebsd.org, Alexander Leidinger , freebsd-current@freebsd.org Subject: Re: CFT/HEADS-UP: linux 2.6.16 emulation 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: Thu, 25 Jan 2007 00:51:51 -0000 On Wed, 2007-01-24 at 15:26 +0100, Tijl Coosemans wrote: > On Wednesday 24 January 2007 03:01, Alexandre "Sunny" Kovalenko wrote: > > With current of yesterday and compat.linux.osrelease=2.6.16 Acrobat > > Reader, Real Player and Firefox (including Flash plugin) seem to behave > > What flash version? Flash plugin 9 is still very unstable for me (2.4.2 > and 2.6.16). Any YouTube video crashes it after anywhere from 5 to 50 > seconds. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Nothing nearly that advanced: RabbitsDen# pkg_info | grep flash linux-flashplugin-7.0r69 Adobe Flash Player NPAPI Plugin RabbitsDen# -- Alexandre "Sunny" Kovalenko From owner-freebsd-emulation@FreeBSD.ORG Thu Jan 25 00:58:15 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7CAE16A400 for ; Thu, 25 Jan 2007 00:58:15 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.freebsd.org (Postfix) with ESMTP id 9864D13C45E for ; Thu, 25 Jan 2007 00:58:15 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.176.159]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JCE00AW7G0FVGK1@vms046.mailsrvcs.net> for emulation@freebsd.org; Wed, 24 Jan 2007 18:57:52 -0600 (CST) Date: Wed, 24 Jan 2007 19:57:41 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <20070124143357.GA24993@stud.fit.vutbr.cz> To: Divacky Roman Message-id: <1169686662.33062.7.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <20070120170723.34c223fb@Magellan.Leidinger.net> <1169604069.1132.3.camel@RabbitsDen.RabbitsLawn.verizon.net> <20070124090227.GA71602@stud.fit.vutbr.cz> <1169642370.1132.4.camel@RabbitsDen.RabbitsLawn.verizon.net> <20070124143357.GA24993@stud.fit.vutbr.cz> Cc: emulation@freebsd.org Subject: Re: CFT/HEADS-UP: linux 2.6.16 emulation 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: Thu, 25 Jan 2007 00:58:15 -0000 On Wed, 2007-01-24 at 15:33 +0100, Divacky Roman wrote: > On Wed, Jan 24, 2007 at 07:39:29AM -0500, Alexandre Sunny Kovalenko wrote: > > On Wed, 2007-01-24 at 10:02 +0100, Divacky Roman wrote: > > > > With current of yesterday and compat.linux.osrelease=2.6.16 Acrobat > > > > Reader, Real Player and Firefox (including Flash plugin) seem to behave > > > > on my ThinkPad X60 (SMP machine). Admittedly use was light, but > > > > hopefully this report will encourage more people to try switching to new > > > > linuxolator. > > > > > > do you have time for some "harder testing"? I am afraid of races and locking > > > bugs in the code. I guess if you could install linux_dist-gentoo-stage3 > > > chroot to it and emerge their portage and try to compile for example firefox > > > (ie. it has to compile X.org and a lot of other packages). if the emulation > > > survives that I am pretty sure about it not panicing easily :) > > > > > > can you do that or something like that? > > > > > > thnx > > > > > > roman > > Kicked off port install. Would try do do some emerging later tonight > > (EST). > > great... thnx for the testing.. Thank you for working on this. However, I seem to be stuck somewhat and I am not sure whether it is me or linuxolator: RabbitsDen# mount -t linprocfs linproc /usr/local/gentoo-stage3/proc RabbitsDen# chroot /usr/local/gentoo-stage3 /bin/bash RabbitsDen / # ping www.mindspring.com WARNING: setsockopt(ICMP_FILTER): Protocol not available WARNING: your kernel is veeery old. No problems. PING www.mindspring.com (199.174.114.42) 56(84) bytes of data. Warning: no SO_TIMESTAMP support, falling back to SIOCGSTAMP ping: sendmsg: Invalid argument ping: recvmsg: Invalid argument ping: sendmsg: Invalid argument ping: recvmsg: Invalid argument ping: sendmsg: Invalid argument ping: recvmsg: Invalid argument ^C --- www.mindspring.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2001ms RabbitsDen / # uname -a Linux RabbitsDen.RabbitsLawn.verizon.net 2.6.16 FreeBSD 7.0-CURRENT #0: Tue Jan 23 09:02:26 EST 2007 i686 Genuine Intel(R) CPU T2400 @ 1.83GHz GenuineIntel GNU/Linux RabbitsDen / # any suggestion will be appreciated. I am not normally using Linux stuff in this mode, so this might as well be pilot error. Alexandre "Sunny" Kovalenko. P.S. I am not subscribing to emulation@, so, please, do not remove me from the list when replying. From owner-freebsd-emulation@FreeBSD.ORG Thu Jan 25 07:26:00 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4FB016A402 for ; Thu, 25 Jan 2007 07:26:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0E213C442 for ; Thu, 25 Jan 2007 07:26:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5CA12.dip.t-dialin.net [84.165.202.18]) by redbull.bpaserver.net (Postfix) with ESMTP id 869552E1B0; Thu, 25 Jan 2007 08:35:38 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id D48015B4873; Thu, 25 Jan 2007 08:25:53 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0P7PrKA046682; Thu, 25 Jan 2007 08:25:53 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 25 Jan 2007 08:25:53 +0100 Message-ID: <20070125082553.m64yjmoku88kgg8s@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 25 Jan 2007 08:25:53 +0100 From: Alexander Leidinger To: "Alexandre \\\\Sunny\\\\ Kovalenko" References: <20070120170723.34c223fb@Magellan.Leidinger.net> <1169604069.1132.3.camel@RabbitsDen.RabbitsLawn.verizon.net> <20070124090227.GA71602@stud.fit.vutbr.cz> <1169642370.1132.4.camel@RabbitsDen.RabbitsLawn.verizon.net> <20070124143357.GA24993@stud.fit.vutbr.cz> <1169686662.33062.7.camel@RabbitsDen.RabbitsLawn.verizon.net> In-Reply-To: <1169686662.33062.7.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.787, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, TW_OC 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: emulation@freebsd.org Subject: Re: CFT/HEADS-UP: linux 2.6.16 emulation 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: Thu, 25 Jan 2007 07:26:00 -0000 Quoting "Alexandre \Sunny\ Kovalenko" =20 (from Wed, 24 Jan 2007 19:57:41 -0500): > RabbitsDen# mount -t linprocfs linproc /usr/local/gentoo-stage3/proc > RabbitsDen# chroot /usr/local/gentoo-stage3 /bin/bash > RabbitsDen / # ping www.mindspring.com > WARNING: setsockopt(ICMP_FILTER): Protocol not available > WARNING: your kernel is veeery old. No problems. > PING www.mindspring.com (199.174.114.42) 56(84) bytes of data. > Warning: no SO_TIMESTAMP support, falling back to SIOCGSTAMP > ping: sendmsg: Invalid argument > ping: recvmsg: Invalid argument We didn't tried to run the network regression tests in the LTP so far... > any suggestion will be appreciated. I am not normally using Linux stuff > in this mode, so this might as well be pilot error. I can't test myself ATM, is there some text in dmesg / on the console =20 after doing the ping? Could you please run the LTP tests (described at =20 http://wiki.FreeBSD.org/linux-kernel) on your SMP system and compare =20 it with the results we have (http://wiki.FreeBSD.org/linux-kernel/ltp)? Bye, Alexander. --=20 Blessed is the man who, having nothing to say, abstains from giving wordy evidence of the fact. =09=09-- George Eliot http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-emulation@FreeBSD.ORG Thu Jan 25 20:12:11 2007 Return-Path: X-Original-To: freebsd-emulation@hub.freebsd.org Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6173916A402; Thu, 25 Jan 2007 20:12:11 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3B20413C43E; Thu, 25 Jan 2007 20:12:11 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from freefall.freebsd.org (pav@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0PKCB4L088604; Thu, 25 Jan 2007 20:12:11 GMT (envelope-from pav@freefall.freebsd.org) Received: (from pav@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0PKCAXo088600; Thu, 25 Jan 2007 20:12:10 GMT (envelope-from pav) Date: Thu, 25 Jan 2007 20:12:10 GMT From: Pav Lucistnik Message-Id: <200701252012.l0PKCAXo088600@freefall.freebsd.org> To: markus@mhoenicka.de, pav@FreeBSD.org, freebsd-emulation@FreeBSD.org Cc: Subject: Re: ports/102474: linux_base-fc-4_8 appears broken, does not allow to run Linux binaries 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: Thu, 25 Jan 2007 20:12:11 -0000 Synopsis: linux_base-fc-4_8 appears broken, does not allow to run Linux binaries State-Changed-From-To: feedback->closed State-Changed-By: pav State-Changed-When: Thu Jan 25 20:00:40 UTC 2007 State-Changed-Why: Solved - nonstandard installation on submitter's machine. The underlaying problem in rtld stays. http://www.freebsd.org/cgi/query-pr.cgi?pr=102474 From owner-freebsd-emulation@FreeBSD.ORG Fri Jan 26 07:21:44 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 239F316A401 for ; Fri, 26 Jan 2007 07:21:44 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD2013C46C for ; Fri, 26 Jan 2007 07:21:43 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so1038196nfc for ; Thu, 25 Jan 2007 23:21:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FNWxr6AGG0QOdDw16JOmZ1SJQT2PcZpEapWKQu+By531L4TjeJTJJFI88yD916lGly/mjnuxF90b1b9KegUemIJ1Qr1raHx53qyEca3kRuvb2oq+S8h4pJFk2BZr5ycKfNvSVdM+6WgkvHfIF2v9F53DQTlNfQNZkey+JkTbeZA= Received: by 10.82.169.4 with SMTP id r4mr1694213bue.1169796101763; Thu, 25 Jan 2007 23:21:41 -0800 (PST) Received: by 10.82.186.2 with HTTP; Thu, 25 Jan 2007 23:21:41 -0800 (PST) Message-ID: <790a9fff0701252321x2c7bea62od928766849e32c68@mail.gmail.com> Date: Fri, 26 Jan 2007 01:21:41 -0600 From: "Scot Hetzel" To: "Alexander Leidinger" In-Reply-To: <20070115105921.wbv2yrd4bkgokcko@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_47613_21023996.1169796101720" References: <790a9fff0701060012x40063f48pc842510b082df5a5@mail.gmail.com> <20070106130830.3c2e6d98@Magellan.Leidinger.net> <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> <20070114105239.GA6955@stud.fit.vutbr.cz> <790a9fff0701141254s2c92b10ag6b042a019bc283c@mail.gmail.com> <20070115105921.wbv2yrd4bkgokcko@webmail.leidinger.net> Cc: freebsd-emulation@freebsd.org Subject: Re: linuxolator: proc/filesystems and sysfs function implementations 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: Fri, 26 Jan 2007 07:21:44 -0000 ------=_Part_47613_21023996.1169796101720 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/15/07, Alexander Leidinger wrote: > Quoting Scot Hetzel (from Sun, 14 Jan 2007 > 14:54:28 -0600): > > > On 1/14/07, Divacky Roman wrote: > > >> + buf = (char *)(uintptr_t)args->arg2; > > : > >> + bsd_to_linux_fs(vfsp->vfc_name, &fs); > >> + len = strlen(fs.name) + 1; > >> + error = copyout(fs.name, buf, len); > >> > >> no need to check if it fits in the userspace buffer? also you > >> dont check return value > >> > > > > According to the linux man page, there isn't a way to check the size > > of buf, as we are only passed the value of the pointer in args->arg2. > > Ugh... there's not even an implicit size because of a fixed definition > of the target buffer in some header? That would be very bad design. > The kernel could overwrite userland data even if the kernel is not > malicious (load a new FS with a too long name and BOOOOM). > > > Should I replace buf with (char *)(uintptr_t)args->arg2 in the > > copyout, since it is only used there. > > > > http://www.die.net/doc/linux/man/man2/sysfs.2.html > > ---snip--- > BUGS > There is no libc or glibc support. There is no way to guess how large > buf should be. > ---snip--- > > That's bad. That's very very bad. I don't like this in the FreeBSD > kernel, I want an upper bound. Would you please try to find some > artificial upper bound? The MFSNAMELEN would be one candidate. A > better candidate would be a similar Linux value. > The patch is using MFSNAMELEN as the upper bound. > >> also... you strcpy string to another string, are you sure it always > >> fits? how do you > >> asure that? > >> > > > > name can't be larger than MFSNAMELEN, and sizeof(fs->name) == MFSNAMELEN. > > Please use strlcpy with the sizeof (defensive programming). > Changed strcpy to strlcpy. > > 16 is the value of MFSNAMELEN and used by the vfsconf struct to define > > the max size of vfc_name. I kept name (in the linux_file_system_type > > Is there a similar value in Linux? It would be better to use this if > it exists. > > > struct) the same size, so that we didn't have to worry about the size > > when using strcpy. > > When you find a value like MFSNAMELEN on Linux, please have a look at > linux_misc.c:linux_prctl(), specially the LINUX_PR_{SET|GET}_NAME case > and the comments in there. What you are doing here should be done > similar. > I wasn't able to locate a value like MFSNAMELEN. I looked at other implementations and the SGI version uses FSTYPESZ (same value as MFSNAMELEN), to limit the size of the buffer. The attached patch is using MFSNAMELEN to limit the size copied in (LINUX_GETFSIND) and copied out (LINUX_GETFSTYPE). LINUX_GETFSTYPE also assumes that the buffer we are copying too is >= MFSNAMELEN. I looked at the LTP sysfs02.c test, and in that file the buffer is set to 40 bytes. Attached is the updated patch, all of the code is now in linux_misc.{c,h}, linprocfs.c and linux_util.h (define for bsd_to_linux_fs function). Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_47613_21023996.1169796101720 Content-Type: text/x-diff; name=sysfs3.patch; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_eiwqe26k Content-Disposition: attachment; filename="sysfs3.patch" SW5kZXg6IGNvbXBhdC9saW5wcm9jZnMvbGlucHJvY2ZzLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTog L2hvbWUvbmN2cy9zcmMvc3lzL2NvbXBhdC9saW5wcm9jZnMvbGlucHJvY2ZzLmMsdgpyZXRyaWV2 aW5nIHJldmlzaW9uIDEuMTA1CmRpZmYgLXUgLXIxLjEwNSBsaW5wcm9jZnMuYwotLS0gY29tcGF0 L2xpbnByb2Nmcy9saW5wcm9jZnMuYwkyMSBKYW4gMjAwNyAxMzoxODo1MiAtMDAwMAkxLjEwNQor KysgY29tcGF0L2xpbnByb2Nmcy9saW5wcm9jZnMuYwkyNiBKYW4gMjAwNiAwMTo1NzowOCAtMDAw MApAQCAtMTA0MSw2ICsxMTMzLDUxIEBACiB9CiAKIC8qCisgKiBGaWxsZXIgZnVuY3Rpb24gZm9y IHByb2MvZmlsZXN5c3RlbXMKKyAqLworc3RhdGljIGludAorbGlucHJvY2ZzX2RvZmlsZXN5c3Rl bXMoUEZTX0ZJTExfQVJHUykKK3sKKwlpbnQgaSwgZnNfZmxhZ3M7CisJY2hhciBmc19uYW1lW01G U05BTUVMRU5dOworCXN0cnVjdCB2ZnNjb25mICp2ZnNwOworCXN0YXRpYyBjaGFyICpsaW51eF9u b2RldmZzW10gPSB7CisJCS8qIEZpbGVzeXN0ZW1zIGluY2x1ZGVkIHdpdGggRnJlZUJTRCAqLwor CQkiY29kYSIsICJkZXZmcyIsICJmZGVzY2ZzIiwgIm1mcyIsICJuZnMiLAorCQkibmZzNCIsICJu dWxsZnMiLCAicG9ydGFsZnMiLCAicHJvY2ZzIiwKKwkJImxpbnByb2NmcyIsICJzbWJmcyIsICJs aW5zeXNmcyIsICJ1bmlvbmZzIiwKKworCQkvKiBGaWxlc3lzdGVtcyBpbmNsdWRlZCB3aXRoIExp bnV4ICovCisJCSI5cCIsICJhZnMiLCAiYXV0b2ZzIiwgImNpZnMiLCAiY29uZmlnZnMiLAorCQki ZGVidWdmcyIsICJkZXZwdHMiLCAiZnVzZSIsICJob3N0ZnMiLAorCQkiaHBwZnMiLCAiaHVnZXRs YmZzIiwgImpmZnMyIiwgIm5jcGZzIiwKKwkJIm5mc2QiLCAib3BlbnByb21mcyIsICJyYW1mcyIs ICJyb290ZnMiLAorCisJCU5VTEwKKwl9OworCisJVEFJTFFfRk9SRUFDSCh2ZnNwLCAmdmZzY29u ZiwgdmZjX2xpc3QpIHsKKworCQkvKiBEb2VzIHRoZSBmaWxlc3lzdGVtIHJlcXVpcmUgYSBkZXYg ZW50cnk/ICovCisJCWZzX2ZsYWdzID0gMTsJLyogRlNfUkVRVUlSRVNfREVWICovCisJCWZvciAo aSA9IDA7IGxpbnV4X25vZGV2ZnNbaV0gIT0gTlVMTDsgaSsrKSB7CisJCQlpZiAoc3RyY21wKGxp bnV4X25vZGV2ZnNbaV0sIHZmc3AtPnZmY19uYW1lKSA9PSAwKSB7CisJCQkgICAgZnNfZmxhZ3Mg PSAwOworCQkJICAgIGJyZWFrOworCQkJfQorCQl9CisKKwkJc3RybGNweShmc19uYW1lLCB2ZnNw LT52ZmNfbmFtZSwgc2l6ZW9mKGZzX25hbWUpKTsKKwkJYnNkX3RvX2xpbnV4X2ZzKGZzX25hbWUp OworCisJCXNidWZfcHJpbnRmKHNiLCAiJXNcdCVzXG4iLCBcCisJCSAgICBmc19mbGFncyA/ICIi IDogIm5vZGV2IiwgZnNfbmFtZSk7CisJfQorCisJcmV0dXJuICgwKTsKK30KKworLyoKICAqIEZp bGxlciBmdW5jdGlvbiBmb3IgcHJvYy9jbWRsaW5lCiAgKi8KIHN0YXRpYyBpbnQKQEAgLTEwODYs NiArMTIyMyw4IEBACiAJICAgIE5VTEwsIE5VTEwsIFBGU19SRCk7CiAJcGZzX2NyZWF0ZV9maWxl KHJvb3QsICJkZXZpY2VzIiwgJmxpbnByb2Nmc19kb2RldmljZXMsCiAJICAgIE5VTEwsIE5VTEws IFBGU19SRCk7CisJcGZzX2NyZWF0ZV9maWxlKHJvb3QsICJmaWxlc3lzdGVtcyIsICZsaW5wcm9j ZnNfZG9maWxlc3lzdGVtcywKKwkgICAgTlVMTCwgTlVMTCwgUEZTX1JEKTsKIAlwZnNfY3JlYXRl X2ZpbGUocm9vdCwgImxvYWRhdmciLCAmbGlucHJvY2ZzX2RvbG9hZGF2ZywKIAkgICAgTlVMTCwg TlVMTCwgUEZTX1JEKTsKIAlwZnNfY3JlYXRlX2ZpbGUocm9vdCwgIm1lbWluZm8iLCAmbGlucHJv Y2ZzX2RvbWVtaW5mbywKSW5kZXg6IGNvbXBhdC9saW51eC9saW51eF9taXNjLmgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2NvbXBhdC9saW51eC9saW51eF9taXNjLmgs dgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMgpkaWZmIC11IC1yMS4yIGxpbnV4X21pc2MuaAotLS0g Y29tcGF0L2xpbnV4L2xpbnV4X21pc2MuaAkzMSBEZWMgMjAwNiAxMTo1NjoxNiAtMDAwMAkxLjIK KysrIGNvbXBhdC9saW51eC9saW51eF9taXNjLmgJMjYgSmFuIDIwMDYgMDI6MTI6MzAgLTAwMDAK QEAgLTQyLDQgKzQyLDkgQEAKIAogI2RlZmluZQlMSU5VWF9NQVhfQ09NTV9MRU4JMTYJLyogTWF4 aW11bSBsZW5ndGggb2YgdGhlIHByb2Nlc3MgbmFtZS4gKi8KIAorLyogZGVmaW5lcyBmb3Igc3lz ZnMgKi8KKyNkZWZpbmUgTElOVVhfR0VURlNJTkQJCTEJLyogVHJhbnNsYXRlIGZpbGVzeXN0ZW0g bmFtZSB0byBpbmRleCAqLworI2RlZmluZSBMSU5VWF9HRVRGU1RZUAkJMgkvKiBUcmFuc2xhdGUg aW5kZXggdG8gZmlsZXN5c3RlbSBuYW1lICovCisjZGVmaW5lIExJTlVYX0dFVE5GU1RZUAkJMwkv KiBSZXR1cm4gdG90YWwgbnVtYmVyIG9mIGZpbGVzeXN0ZW1zICovCisKICNlbmRpZgkvKiBfTElO VVhfTUlTQ19IXyAqLwpJbmRleDogY29tcGF0L2xpbnV4L2xpbnV4X3V0aWwuaAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvY29tcGF0L2xpbnV4L2xpbnV4X3V0aWwuaCx2 CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yOApkaWZmIC11IC1yMS4yOCBsaW51eF91dGlsLmgKLS0t IGNvbXBhdC9saW51eC9saW51eF91dGlsLmgJMjcgSnVuIDIwMDYgMTg6MzA6NDkgLTAwMDAJMS4y OAorKysgY29tcGF0L2xpbnV4L2xpbnV4X3V0aWwuaAkyNiBKYW4gMjAwNiAwMjowMTozNCAtMDAw MApAQCAtMTAxLDQgKzEwMyw3IEBACiBjaGFyCSpsaW51eF9nZXRfY2hhcl9kZXZpY2VzKHZvaWQp Owogdm9pZAlsaW51eF9mcmVlX2dldF9jaGFyX2RldmljZXMoY2hhciAqc3RyaW5nKTsKIAorLyog dXNlZCBieSBzeXNmcyBhbmQgbGlucHJvY2ZzX2RvZmlsZXN5c3RlbXMgZnVuY3Rpb25zICovCit2 b2lkCWJzZF90b19saW51eF9mcyhjaGFyICpuYW1lKTsKKwogI2VuZGlmIC8qICFfTElOVVhfVVRJ TF9IXyAqLwpJbmRleDogYW1kNjQvbGludXgzMi9saW51eDMyX2R1bW15LmMKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpS Q1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2FtZDY0L2xpbnV4MzIvbGludXgzMl9kdW1teS5j LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjcKZGlmZiAtdSAtcjEuNyBsaW51eDMyX2R1bW15LmMK LS0tIGFtZDY0L2xpbnV4MzIvbGludXgzMl9kdW1teS5jCTMxIERlYyAyMDA2IDEzOjE2OjAwIC0w MDAwCTEuNworKysgYW1kNjQvbGludXgzMi9saW51eDMyX2R1bW15LmMJMTYgSmFuIDIwMDcgMDI6 NDI6MDMgLTAwMDAKQEAgLTUwLDYgKzUwLDUgQEAKIERVTU1ZKGdldF9rZXJuZWxfc3ltcyk7CiBE VU1NWShxdW90YWN0bCk7CiBEVU1NWShiZGZsdXNoKTsKLURVTU1ZKHN5c2ZzKTsKIERVTU1ZKHF1 ZXJ5X21vZHVsZSk7CiBEVU1NWShuZnNzZXJ2Y3RsKTsKSW5kZXg6IGkzODYvbGludXgvbGludXhf ZHVtbXkuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvaTM4Ni9saW51 eC9saW51eF9kdW1teS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjQ1CmRpZmYgLXUgLXIxLjQ1 IGxpbnV4X2R1bW15LmMKLS0tIGkzODYvbGludXgvbGludXhfZHVtbXkuYwkzMSBEZWMgMjAwNiAx MzoxNjowMCAtMDAwMAkxLjQ1CisrKyBpMzg2L2xpbnV4L2xpbnV4X2R1bW15LmMJMTYgSmFuIDIw MDcgMDM6MDI6NTYgLTAwMDAKQEAgLTUyLDYgKzUyLDUgQEAKIERVTU1ZKGdldF9rZXJuZWxfc3lt cyk7CiBEVU1NWShxdW90YWN0bCk7CiBEVU1NWShiZGZsdXNoKTsKLURVTU1ZKHN5c2ZzKTsKIERV TU1ZKHZtODYpOwogRFVNTVkocXVlcnlfbW9kdWxlKTsKSW5kZXg6IGNvbXBhdC9saW51eC9saW51 eF9taXNjLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2NvbXBhdC9s aW51eC9saW51eF9taXNjLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjA1CmRpZmYgLXUgLXIx LjIwNSBsaW51eF9taXNjLmMKLS0tIGNvbXBhdC9saW51eC9saW51eF9taXNjLmMJNyBKYW4gMjAw NyAxOTozMDoxOSAtMDAwMAkxLjIwNQorKysgY29tcGF0L2xpbnV4L2xpbnV4X21pc2MuYwkyNiBK YW4gMjAwNiAwNDo1Njo1MiAtMDAwMApAQCAtMTcxNiwzICsxNzI5LDExNCBAQAogewogCXJldHVy biAoY2hyb290KHRkLCAoc3RydWN0IGNocm9vdF9hcmdzICopYXJncykpOwogfQorCisvKiB0YWJs ZSB1c2VkIHRvIGRlcml2ZSBsaW51eCBmaWxlc3lzdGVtIG5hbWVzIHRvL2Zyb20gZnJlZWJzZCBm aWxlc3lzdGVtIG5hbWVzICovCitzdGF0aWMgc3RydWN0IHtjb25zdCBjaGFyICpsX25hbWU7IGNv bnN0IGNoYXIgKmJfbmFtZTt9IGwyYmZzX3RibFtdID0geworCXsgImV4dDIiLCAiZXh0MmZzIiB9 LAorCXsgImV4dDMiLCAiZXh0MmZzIn0sCisJeyAiaXNvOTY2MCIsICJjZDk2NjAifSwKKwl7ICJt c2RvcyIsICJtc2Rvc2ZzIn0sCisJeyAiYnNkcHJvY2ZzIiwgInByb2NmcyJ9LAorCXsgInByb2Mi LCAibGlucHJvY2ZzIn0sCisJeyAic3lzZnMiLCAibGluc3lzZnMifSwKKwl7ICJ1ZnMiLCAiZmZz In0sCisJeyAidmZhdCIsICJtc2Rvc2ZzIn0sCisJeyBOVUxMLCBOVUxMIH0KK307CisKKy8qIAor ICogVHJhbnNsYXRlIGJzZCBmaWxlc3lzdGVtIG5hbWUgdG8gbGludXggZmlsZXN5c3RlbSBuYW1l CisgKiB1c2VkIGJ5IGxpbnByb2Nmc19kb2ZpbGVzeXN0ZW1zIGFuZCBzeXNmcyBMSU5VWF9HRVRG U1RZUAorICovCit2b2lkCitic2RfdG9fbGludXhfZnMoY2hhciAqbmFtZSkKK3sKKwlpbnQgaTsK KworCWZvciAoIGkgPSAwOyBsMmJmc190YmxbaV0uYl9uYW1lICE9IE5VTEw7IGkrKykgeworCQlp ZiAoc3RyY21wKGwyYmZzX3RibFtpXS5iX25hbWUsIG5hbWUpID09IDApIHsKKwkJCXN0cmxjcHko bmFtZSwgbDJiZnNfdGJsW2ldLmxfbmFtZSwgc2l6ZW9mKG5hbWUpKTsKKwkJCWJyZWFrOworCQl9 CisJfQorfQorCitpbnQKK2xpbnV4X3N5c2ZzKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3QgbGlu dXhfc3lzZnNfYXJncyAqYXJncykKK3sKKwlpbnQgaSwgZXJyb3I9MDsKKwl1bnNpZ25lZCBpbnQg aW5kZXggPSAwOworCWNoYXIgZnNfbmFtZVtNRlNOQU1FTEVOXTsKKwlzdHJ1Y3QgdmZzY29uZiAq dmZzcDsKKworCXN3aXRjaCAoYXJncy0+b3B0aW9uKSB7CisJCS8qCisJCSAqIFRyYW5zbGF0ZSB0 aGUgZmlsZXN5c3RlbSBpZGVudGlmaWVyIHN0cmluZyBpbnRvIGEKKwkJICogZmlsZXN5c3RlbSB0 eXBlIGluZGV4LgorCQkgKi8KKwkJY2FzZSBMSU5VWF9HRVRGU0lORDoKKwkJCS8qIElzIGFyZ3Mt PmFyZzEgdmFsaWQsIGlmIG5vdCB2YWxpZCByZXR1cm4gRUZBVUxUICovCisJCQllcnJvciA9IGNv cHlpbnN0cigodm9pZCAqKShyZWdpc3Rlcl90KWFyZ3MtPmFyZzEsIGZzX25hbWUsCisJCQkJCSAg TUZTTkFNRUxFTiwgTlVMTCk7CisJCQlpZiAoZXJyb3IpIHsKKwkJCQlyZXR1cm4gKGVycm9yKTsK KyAJCQl9CisKKwkJCWZvciAoIGkgPSAwOyBsMmJmc190YmxbaV0ubF9uYW1lICE9IE5VTEw7IGkr KykgeworCQkJCWlmIChzdHJjbXAobDJiZnNfdGJsW2ldLmxfbmFtZSwgZnNfbmFtZSkgPT0gMCkg eworCQkJCQlzdHJsY3B5KGZzX25hbWUsIGwyYmZzX3RibFtpXS5iX25hbWUsCisJCQkJCQlzaXpl b2YoZnNfbmFtZSkpOworCQkJCQlicmVhazsKKwkJCQl9CisJCQl9CisKKwkJCVRBSUxRX0ZPUkVB Q0godmZzcCwgJnZmc2NvbmYsIHZmY19saXN0KQorCQkJCWlmIChzdHJjbXAodmZzcC0+dmZjX25h bWUsIGZzX25hbWUpID09IDApIHsKKwkJCQkJdGQtPnRkX3JldHZhbFswXSA9IGluZGV4OworCQkJ CQlicmVhazsKKwkJCQl9IGVsc2UKKwkJCQkJaW5kZXgrKzsKKwkJCWlmICghdmZzcCkKKwkJCQly ZXR1cm4gKEVJTlZBTCk7CisJCQlicmVhazsKKworCQkvKgorCQkgKiBUcmFuc2xhdGUgdGhlIGZp bGUtc3lzdGVtIHR5cGUgaW5kZXggaW50byBhCisJCSAqIG51bGwtdGVybWluYXRlZCBmaWxlc3lz dGVtIGlkZW50aWZpZXIgc3RyaW5nLgorCQkgKi8KKwkJY2FzZSBMSU5VWF9HRVRGU1RZUDoKKwkJ CWluZGV4ID0gYXJncy0+YXJnMTsKKworCQkJVEFJTFFfRk9SRUFDSCh2ZnNwLCAmdmZzY29uZiwg dmZjX2xpc3QpCisJCQkJaWYgKGluZGV4LS0gPD0gMCkKKwkJCQkJYnJlYWs7CisJCQlpZiAoIXZm c3ApCisJCQkJcmV0dXJuIChFSU5WQUwpOworCisJCQlzdHJsY3B5KGZzX25hbWUsIHZmc3AtPnZm Y19uYW1lLCBzaXplb2YoZnNfbmFtZSkpOworCQkJYnNkX3RvX2xpbnV4X2ZzKGZzX25hbWUpOwor CisJCQkvKgorCQkJICogV2UgYXNzdW1lIHRoYXQgdGhlIGJ1ZmZlciBwb2ludGVkIHRvIGJ5CisJ CQkgKiAodm9pZCAqKShyZWdpc3Rlcl90KWFyZ3MtPmFyZzIgaXMgZ3JlYXRlciB0aGFuIE1GU05B TUVMRU4KKwkJCSAqLworCQkJZXJyb3IgPSBjb3B5b3V0KGZzX25hbWUsICh2b2lkICopKHJlZ2lz dGVyX3QpYXJncy0+YXJnMiwKKwkJCQkJTUZTTkFNRUxFTik7CisJCQlicmVhazsKKworCQkvKgor CQkgKiBSZXR1cm4gdGhlIHRvdGFsIG51bWJlciBvZiBmaWxlIHN5c3RlbSB0eXBlcworCQkgKiBj dXJyZW50bHkgcHJlc2VudCBpbiB0aGUga2VybmVsLgorCQkgKi8KKwkJY2FzZSBMSU5VWF9HRVRO RlNUWVA6CisJCQlUQUlMUV9GT1JFQUNIKHZmc3AsICZ2ZnNjb25mLCB2ZmNfbGlzdCkKKwkJCQlp bmRleCsrOworCQkJdGQtPnRkX3JldHZhbFswXSA9IGluZGV4OworCQkJYnJlYWs7CisKKwkJLyog SW52YWxpZCBvcHRpb24gcGFzc2VkICovCisJCWRlZmF1bHQ6CisJCQllcnJvciA9IEVJTlZBTDsK Kwl9CisJcmV0dXJuIChlcnJvcik7Cit9Cg== ------=_Part_47613_21023996.1169796101720-- From owner-freebsd-emulation@FreeBSD.ORG Fri Jan 26 07:24:58 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0BD816A400 for ; Fri, 26 Jan 2007 07:24:58 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 8999913C458 for ; Fri, 26 Jan 2007 07:24:58 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so1038883nfc for ; Thu, 25 Jan 2007 23:24:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pnEi73ZZdgFNCZZVEbheJvoUtAZSOriNsDmGUYjJ7ZmkwwcLWQHR13KP1yiZzVg3ima05eaO6d1+8+llezdcoNPbs8yOvXdk/uxLN1tzjP+ziCVCub2mAqpngPyXblLVHe6Vpf/yPhL/0Uz4k1o7D/dBTsrBfIGl7b6q1fw/gvY= Received: by 10.82.118.2 with SMTP id q2mr1699947buc.1169796296020; Thu, 25 Jan 2007 23:24:56 -0800 (PST) Received: by 10.82.186.2 with HTTP; Thu, 25 Jan 2007 23:24:55 -0800 (PST) Message-ID: <790a9fff0701252324h64a6e291x20ce79a00f364aa2@mail.gmail.com> Date: Fri, 26 Jan 2007 01:24:55 -0600 From: "Scot Hetzel" To: "Alexander Leidinger" In-Reply-To: <20070115105921.wbv2yrd4bkgokcko@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0701060012x40063f48pc842510b082df5a5@mail.gmail.com> <20070106130830.3c2e6d98@Magellan.Leidinger.net> <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> <20070114105239.GA6955@stud.fit.vutbr.cz> <790a9fff0701141254s2c92b10ag6b042a019bc283c@mail.gmail.com> <20070115105921.wbv2yrd4bkgokcko@webmail.leidinger.net> Cc: freebsd-emulation@freebsd.org Subject: Re: linuxolator: proc/filesystems and sysfs function implementations 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: Fri, 26 Jan 2007 07:24:59 -0000 On 1/15/07, Alexander Leidinger wrote: > Do you intend to submit more patches to the linuxulator? If yes, do > you want to get write access to our perforce repository (that's not an > official CVS or developer account, but a step in this direction)? If > yes, what username do you prefer? > I haven't looked at what else I could work on for the linuxulator, and right now I have some work that I'm a little behind on. I'll let you know latter if I need write access to perforce, thanks for the offer. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-emulation@FreeBSD.ORG Fri Jan 26 23:21:15 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBAB016A403 for ; Fri, 26 Jan 2007 23:21:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7C613C4A3 for ; Fri, 26 Jan 2007 23:21:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l0QNLEXN011972; Fri, 26 Jan 2007 18:21:14 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-amd64@FreeBSD.org Date: Fri, 26 Jan 2007 18:21:09 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701261821.12274.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2493/Fri Jan 26 07:00:46 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-emulation@FreeBSD.org Subject: load_fs() and load_gs() 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: Fri, 26 Jan 2007 23:21:15 -0000 I have been chasing TLS problem for Linuxulator/amd64. The whole thing actually boils down to the following simulation: ---------------- #include #include #include #include static __thread u_int tls = 0xdeadbeef; int main(void) { #if defined(__amd64__) u_int fs; uint64_t fsbase; fs = rfs(); if (sysarch(AMD64_GET_FSBASE, &fsbase)) return (-1); printf("fsbase = 0x%lx, %%fs: 0x%08x, tls = 0x%x\n", fsbase, fs, tls); /* * glibc does the following two calls. * Note: Actually we don't do anything here * but writing them back. */ if (sysarch(AMD64_SET_FSBASE, &fsbase)) return (-1); load_fs(fs); if (sysarch(AMD64_GET_FSBASE, &fsbase)) return (-1); printf("fsbase = 0x%lx, %%fs: 0x%08x, tls = 0x%x\n", fsbase, rfs(), tls); #elif defined(__i386__) u_int gs; uint32_t gsbase; gs = rgs(); if (sysarch(I386_GET_GSBASE, &gsbase)) return (-1); printf("gsbase = 0x%lx, %%gs: 0x%08x, tls = 0x%x\n", gsbase, gs, tls); /* * glibc does the following two calls. * Note: Actually we don't do anything here * but writing them back. */ if (sysarch(I386_SET_GSBASE, &gsbase)) return (-1); load_gs(gs); if (sysarch(I386_GET_GSBASE, &gsbase)) return (-1); printf("gsbase = 0x%lx, %%gs: 0x%08x, tls = 0x%x\n", gsbase, rgs(), tls); #endif return (0); } ---------------- If you run it on amd64 (both amd64 and i386 binaries), it segfaults at: mov %fs:0x0,%rax (amd64) or mov %gs:0x0,%eax (i386) which is basically reading tls. Why does it segfaults when we just read and write them back? Can anyone enlighten me? Thanks, Jung-uk Kim From owner-freebsd-emulation@FreeBSD.ORG Fri Jan 26 23:50:36 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 375C716A400 for ; Fri, 26 Jan 2007 23:50:36 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 79A2413C483 for ; Fri, 26 Jan 2007 23:50:35 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so1244353nfc for ; Fri, 26 Jan 2007 15:50:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ncAO+R5JoFZMRtJpRFIbK718px3Y38hNFE/FNyA5bCRYtt9PzcAn9k7N0yC8lMEcWd0aNBY31Y1+2IadtEp9IRPYNnLhUbfAI2NxM+mDjUuk4JVSvYXHTbM4rVGQ1rOkbYX/OtUmj8gi8CaNnXTsbF9E4yQA34oVl/ci0JR20pY= Received: by 10.82.116.15 with SMTP id o15mr2282998buc.1169855433668; Fri, 26 Jan 2007 15:50:33 -0800 (PST) Received: by 10.82.186.2 with HTTP; Fri, 26 Jan 2007 15:50:33 -0800 (PST) Message-ID: <790a9fff0701261550n5982c0chea94dbfa208439da@mail.gmail.com> Date: Fri, 26 Jan 2007 17:50:33 -0600 From: "Scot Hetzel" To: "Alexander Leidinger" In-Reply-To: <790a9fff0701252321x2c7bea62od928766849e32c68@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_63956_28802723.1169855433358" References: <790a9fff0701060012x40063f48pc842510b082df5a5@mail.gmail.com> <20070106130830.3c2e6d98@Magellan.Leidinger.net> <790a9fff0701132017g6c081567la4a759cea4618535@mail.gmail.com> <20070114105239.GA6955@stud.fit.vutbr.cz> <790a9fff0701141254s2c92b10ag6b042a019bc283c@mail.gmail.com> <20070115105921.wbv2yrd4bkgokcko@webmail.leidinger.net> <790a9fff0701252321x2c7bea62od928766849e32c68@mail.gmail.com> Cc: freebsd-emulation@freebsd.org Subject: Re: linuxolator: proc/filesystems and sysfs function implementations 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: Fri, 26 Jan 2007 23:50:36 -0000 ------=_Part_63956_28802723.1169855433358 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Opps made a small mistake in the bsd_to_linux_fs function, I had used sizeof(name) in the strlcpy, but that returns the size of the pointer. I have renamed the function to make it more descriptive, and it now takes 2 arguments [ bsd2linux_fsname(char *name, int size) ], size is now used in the strlcpy instead of sizeof(name). Attached is the updated patch. -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_63956_28802723.1169855433358 Content-Type: text/x-diff; name="sysfs4.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sysfs4.patch" X-Attachment-Id: f_exewt7ib SW5kZXg6IGNvbXBhdC9saW5wcm9jZnMvbGlucHJvY2ZzLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTog L2hvbWUvbmN2cy9zcmMvc3lzL2NvbXBhdC9saW5wcm9jZnMvbGlucHJvY2ZzLmMsdgpyZXRyaWV2 aW5nIHJldmlzaW9uIDEuMTA1CmRpZmYgLXUgLXIxLjEwNSBsaW5wcm9jZnMuYwotLS0gY29tcGF0 L2xpbnByb2Nmcy9saW5wcm9jZnMuYwkyMSBKYW4gMjAwNyAxMzoxODo1MiAtMDAwMAkxLjEwNQor KysgY29tcGF0L2xpbnByb2Nmcy9saW5wcm9jZnMuYwkyNiBKYW4gMjAwNiAwMTo1NzowOCAtMDAw MApAQCAtMTA0MSw2ICsxMTMzLDUxIEBACiB9CiAKIC8qCisgKiBGaWxsZXIgZnVuY3Rpb24gZm9y IHByb2MvZmlsZXN5c3RlbXMKKyAqLworc3RhdGljIGludAorbGlucHJvY2ZzX2RvZmlsZXN5c3Rl bXMoUEZTX0ZJTExfQVJHUykKK3sKKwlpbnQgaSwgZnNfZmxhZ3M7CisJY2hhciBmc19uYW1lW01G U05BTUVMRU5dOworCXN0cnVjdCB2ZnNjb25mICp2ZnNwOworCXN0YXRpYyBjaGFyICpsaW51eF9u b2RldmZzW10gPSB7CisJCS8qIEZpbGVzeXN0ZW1zIGluY2x1ZGVkIHdpdGggRnJlZUJTRCAqLwor CQkiY29kYSIsICJkZXZmcyIsICJmZGVzY2ZzIiwgIm1mcyIsICJuZnMiLAorCQkibmZzNCIsICJu dWxsZnMiLCAicG9ydGFsZnMiLCAicHJvY2ZzIiwKKwkJImxpbnByb2NmcyIsICJzbWJmcyIsICJs aW5zeXNmcyIsICJ1bmlvbmZzIiwKKworCQkvKiBGaWxlc3lzdGVtcyBpbmNsdWRlZCB3aXRoIExp bnV4ICovCisJCSI5cCIsICJhZnMiLCAiYXV0b2ZzIiwgImNpZnMiLCAiY29uZmlnZnMiLAorCQki ZGVidWdmcyIsICJkZXZwdHMiLCAiZnVzZSIsICJob3N0ZnMiLAorCQkiaHBwZnMiLCAiaHVnZXRs YmZzIiwgImpmZnMyIiwgIm5jcGZzIiwKKwkJIm5mc2QiLCAib3BlbnByb21mcyIsICJyYW1mcyIs ICJyb290ZnMiLAorCisJCU5VTEwKKwl9OworCisJVEFJTFFfRk9SRUFDSCh2ZnNwLCAmdmZzY29u ZiwgdmZjX2xpc3QpIHsKKworCQkvKiBEb2VzIHRoZSBmaWxlc3lzdGVtIHJlcXVpcmUgYSBkZXYg ZW50cnk/ICovCisJCWZzX2ZsYWdzID0gMTsJLyogRlNfUkVRVUlSRVNfREVWICovCisJCWZvciAo aSA9IDA7IGxpbnV4X25vZGV2ZnNbaV0gIT0gTlVMTDsgaSsrKSB7CisJCQlpZiAoc3RyY21wKGxp bnV4X25vZGV2ZnNbaV0sIHZmc3AtPnZmY19uYW1lKSA9PSAwKSB7CisJCQkgICAgZnNfZmxhZ3Mg PSAwOworCQkJICAgIGJyZWFrOworCQkJfQorCQl9CisKKwkJc3RybGNweShmc19uYW1lLCB2ZnNw LT52ZmNfbmFtZSwgc2l6ZW9mKGZzX25hbWUpKTsKKwkJYnNkMmxpbnV4X2ZzbmFtZShmc19uYW1l LCBzaXplb2YoZnNfbmFtZSkpOworCisJCXNidWZfcHJpbnRmKHNiLCAiJXNcdCVzXG4iLCBcCisJ CSAgICBmc19mbGFncyA/ICIiIDogIm5vZGV2IiwgZnNfbmFtZSk7CisJfQorCisJcmV0dXJuICgw KTsKK30KKworLyoKICAqIEZpbGxlciBmdW5jdGlvbiBmb3IgcHJvYy9jbWRsaW5lCiAgKi8KIHN0 YXRpYyBpbnQKQEAgLTEwODYsNiArMTIyMyw4IEBACiAJICAgIE5VTEwsIE5VTEwsIFBGU19SRCk7 CiAJcGZzX2NyZWF0ZV9maWxlKHJvb3QsICJkZXZpY2VzIiwgJmxpbnByb2Nmc19kb2RldmljZXMs CiAJICAgIE5VTEwsIE5VTEwsIFBGU19SRCk7CisJcGZzX2NyZWF0ZV9maWxlKHJvb3QsICJmaWxl c3lzdGVtcyIsICZsaW5wcm9jZnNfZG9maWxlc3lzdGVtcywKKwkgICAgTlVMTCwgTlVMTCwgUEZT X1JEKTsKIAlwZnNfY3JlYXRlX2ZpbGUocm9vdCwgImxvYWRhdmciLCAmbGlucHJvY2ZzX2RvbG9h ZGF2ZywKIAkgICAgTlVMTCwgTlVMTCwgUEZTX1JEKTsKIAlwZnNfY3JlYXRlX2ZpbGUocm9vdCwg Im1lbWluZm8iLCAmbGlucHJvY2ZzX2RvbWVtaW5mbywKSW5kZXg6IGNvbXBhdC9saW51eC9saW51 eF9taXNjLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2NvbXBhdC9s aW51eC9saW51eF9taXNjLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMgpkaWZmIC11IC1yMS4y IGxpbnV4X21pc2MuaAotLS0gY29tcGF0L2xpbnV4L2xpbnV4X21pc2MuaAkzMSBEZWMgMjAwNiAx MTo1NjoxNiAtMDAwMAkxLjIKKysrIGNvbXBhdC9saW51eC9saW51eF9taXNjLmgJMjYgSmFuIDIw MDYgMDI6MTI6MzAgLTAwMDAKQEAgLTQyLDQgKzQyLDkgQEAKIAogI2RlZmluZQlMSU5VWF9NQVhf Q09NTV9MRU4JMTYJLyogTWF4aW11bSBsZW5ndGggb2YgdGhlIHByb2Nlc3MgbmFtZS4gKi8KIAor LyogZGVmaW5lcyBmb3Igc3lzZnMgKi8KKyNkZWZpbmUgTElOVVhfR0VURlNJTkQJCTEJLyogVHJh bnNsYXRlIGZpbGVzeXN0ZW0gbmFtZSB0byBpbmRleCAqLworI2RlZmluZSBMSU5VWF9HRVRGU1RZ UAkJMgkvKiBUcmFuc2xhdGUgaW5kZXggdG8gZmlsZXN5c3RlbSBuYW1lICovCisjZGVmaW5lIExJ TlVYX0dFVE5GU1RZUAkJMwkvKiBSZXR1cm4gdG90YWwgbnVtYmVyIG9mIGZpbGVzeXN0ZW1zICov CisKICNlbmRpZgkvKiBfTElOVVhfTUlTQ19IXyAqLwpJbmRleDogY29tcGF0L2xpbnV4L2xpbnV4 X3V0aWwuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvY29tcGF0L2xp bnV4L2xpbnV4X3V0aWwuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yOApkaWZmIC11IC1yMS4y OCBsaW51eF91dGlsLmgKLS0tIGNvbXBhdC9saW51eC9saW51eF91dGlsLmgJMjcgSnVuIDIwMDYg MTg6MzA6NDkgLTAwMDAJMS4yOAorKysgY29tcGF0L2xpbnV4L2xpbnV4X3V0aWwuaAkyNiBKYW4g MjAwNiAwMjowMTozNCAtMDAwMApAQCAtMTAxLDQgKzEwMyw3IEBACiBjaGFyCSpsaW51eF9nZXRf Y2hhcl9kZXZpY2VzKHZvaWQpOwogdm9pZAlsaW51eF9mcmVlX2dldF9jaGFyX2RldmljZXMoY2hh ciAqc3RyaW5nKTsKIAorLyogdXNlZCBieSBzeXNmcyBhbmQgbGlucHJvY2ZzX2RvZmlsZXN5c3Rl bXMgZnVuY3Rpb25zICovCit2b2lkCWJzZDJsaW51eF9mc25hbWUoY2hhciAqbmFtZSwgaW50IHNp emUpOworCiAjZW5kaWYgLyogIV9MSU5VWF9VVElMX0hfICovCkluZGV4OiBhbWQ2NC9saW51eDMy L2xpbnV4MzJfZHVtbXkuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMv YW1kNjQvbGludXgzMi9saW51eDMyX2R1bW15LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNwpk aWZmIC11IC1yMS43IGxpbnV4MzJfZHVtbXkuYwotLS0gYW1kNjQvbGludXgzMi9saW51eDMyX2R1 bW15LmMJMzEgRGVjIDIwMDYgMTM6MTY6MDAgLTAwMDAJMS43CisrKyBhbWQ2NC9saW51eDMyL2xp bnV4MzJfZHVtbXkuYwkxNiBKYW4gMjAwNyAwMjo0MjowMyAtMDAwMApAQCAtNTAsNiArNTAsNSBA QAogRFVNTVkoZ2V0X2tlcm5lbF9zeW1zKTsKIERVTU1ZKHF1b3RhY3RsKTsKIERVTU1ZKGJkZmx1 c2gpOwotRFVNTVkoc3lzZnMpOwogRFVNTVkocXVlcnlfbW9kdWxlKTsKIERVTU1ZKG5mc3NlcnZj dGwpOwpJbmRleDogaTM4Ni9saW51eC9saW51eF9kdW1teS5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6 IC9ob21lL25jdnMvc3JjL3N5cy9pMzg2L2xpbnV4L2xpbnV4X2R1bW15LmMsdgpyZXRyaWV2aW5n IHJldmlzaW9uIDEuNDUKZGlmZiAtdSAtcjEuNDUgbGludXhfZHVtbXkuYwotLS0gaTM4Ni9saW51 eC9saW51eF9kdW1teS5jCTMxIERlYyAyMDA2IDEzOjE2OjAwIC0wMDAwCTEuNDUKKysrIGkzODYv bGludXgvbGludXhfZHVtbXkuYwkxNiBKYW4gMjAwNyAwMzowMjo1NiAtMDAwMApAQCAtNTIsNiAr NTIsNSBAQAogRFVNTVkoZ2V0X2tlcm5lbF9zeW1zKTsKIERVTU1ZKHF1b3RhY3RsKTsKIERVTU1Z KGJkZmx1c2gpOwotRFVNTVkoc3lzZnMpOwogRFVNTVkodm04Nik7CiBEVU1NWShxdWVyeV9tb2R1 bGUpOwpJbmRleDogY29tcGF0L2xpbnV4L2xpbnV4X21pc2MuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxl OiAvaG9tZS9uY3ZzL3NyYy9zeXMvY29tcGF0L2xpbnV4L2xpbnV4X21pc2MuYyx2CnJldHJpZXZp bmcgcmV2aXNpb24gMS4yMDUKZGlmZiAtdSAtcjEuMjA1IGxpbnV4X21pc2MuYwotLS0gY29tcGF0 L2xpbnV4L2xpbnV4X21pc2MuYwk3IEphbiAyMDA3IDE5OjMwOjE5IC0wMDAwCTEuMjA1CisrKyBj b21wYXQvbGludXgvbGludXhfbWlzYy5jCTI2IEphbiAyMDA2IDA0OjU2OjUyIC0wMDAwCkBAIC0x NzE2LDMgKzE3MjksMTE0IEBACiB7CiAJcmV0dXJuIChjaHJvb3QodGQsIChzdHJ1Y3QgY2hyb290 X2FyZ3MgKilhcmdzKSk7CiB9CisKKy8qIHRhYmxlIHVzZWQgdG8gZGVyaXZlIGxpbnV4IGZpbGVz eXN0ZW0gbmFtZXMgdG8vZnJvbSBmcmVlYnNkIGZpbGVzeXN0ZW0gbmFtZXMgKi8KK3N0YXRpYyBz dHJ1Y3Qge2NvbnN0IGNoYXIgKmxfbmFtZTsgY29uc3QgY2hhciAqYl9uYW1lO30gbDJiZnNfdGJs W10gPSB7CisJeyAiZXh0MiIsICJleHQyZnMiIH0sCisJeyAiZXh0MyIsICJleHQyZnMifSwKKwl7 ICJpc285NjYwIiwgImNkOTY2MCJ9LAorCXsgIm1zZG9zIiwgIm1zZG9zZnMifSwKKwl7ICJic2Rw cm9jZnMiLCAicHJvY2ZzIn0sCisJeyAicHJvYyIsICJsaW5wcm9jZnMifSwKKwl7ICJzeXNmcyIs ICJsaW5zeXNmcyJ9LAorCXsgInVmcyIsICJmZnMifSwKKwl7ICJ2ZmF0IiwgIm1zZG9zZnMifSwK Kwl7IE5VTEwsIE5VTEwgfQorfTsKKworLyogCisgKiBUcmFuc2xhdGUgYnNkIGZpbGVzeXN0ZW0g bmFtZSB0byBsaW51eCBmaWxlc3lzdGVtIG5hbWUKKyAqIHVzZWQgYnkgbGlucHJvY2ZzX2RvZmls ZXN5c3RlbXMgYW5kIHN5c2ZzIExJTlVYX0dFVEZTVFlQCisgKi8KK3ZvaWQKK2JzZDJsaW51eF9m c25hbWUoY2hhciAqbmFtZSwgaW50IHNpemUpCit7CisJaW50IGk7CisKKwlmb3IgKCBpID0gMDsg bDJiZnNfdGJsW2ldLmJfbmFtZSAhPSBOVUxMOyBpKyspIHsKKwkJaWYgKHN0cmNtcChsMmJmc190 YmxbaV0uYl9uYW1lLCBuYW1lKSA9PSAwKSB7CisJCQlzdHJsY3B5KG5hbWUsIGwyYmZzX3RibFtp XS5sX25hbWUsIHNpemUpOworCQkJYnJlYWs7CisJCX0KKwl9Cit9CisKK2ludAorbGludXhfc3lz ZnMoc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBsaW51eF9zeXNmc19hcmdzICphcmdzKQorewor CWludCBpLCBlcnJvcj0wOworCXVuc2lnbmVkIGludCBpbmRleCA9IDA7CisJY2hhciBmc19uYW1l W01GU05BTUVMRU5dOworCXN0cnVjdCB2ZnNjb25mICp2ZnNwOworCisJc3dpdGNoIChhcmdzLT5v cHRpb24pIHsKKwkJLyoKKwkJICogVHJhbnNsYXRlIHRoZSBmaWxlc3lzdGVtIGlkZW50aWZpZXIg c3RyaW5nIGludG8gYQorCQkgKiBmaWxlc3lzdGVtIHR5cGUgaW5kZXguCisJCSAqLworCQljYXNl IExJTlVYX0dFVEZTSU5EOgorCQkJLyogSXMgYXJncy0+YXJnMSB2YWxpZCwgaWYgbm90IHZhbGlk IHJldHVybiBFRkFVTFQgKi8KKwkJCWVycm9yID0gY29weWluc3RyKCh2b2lkICopKHJlZ2lzdGVy X3QpYXJncy0+YXJnMSwgZnNfbmFtZSwKKwkJCQkJICBNRlNOQU1FTEVOLCBOVUxMKTsKKwkJCWlm IChlcnJvcikgeworCQkJCXJldHVybiAoZXJyb3IpOworIAkJCX0KKworCQkJZm9yICggaSA9IDA7 IGwyYmZzX3RibFtpXS5sX25hbWUgIT0gTlVMTDsgaSsrKSB7CisJCQkJaWYgKHN0cmNtcChsMmJm c190YmxbaV0ubF9uYW1lLCBmc19uYW1lKSA9PSAwKSB7CisJCQkJCXN0cmxjcHkoZnNfbmFtZSwg bDJiZnNfdGJsW2ldLmJfbmFtZSwKKwkJCQkJCXNpemVvZihmc19uYW1lKSk7CisJCQkJCWJyZWFr OworCQkJCX0KKwkJCX0KKworCQkJVEFJTFFfRk9SRUFDSCh2ZnNwLCAmdmZzY29uZiwgdmZjX2xp c3QpCisJCQkJaWYgKHN0cmNtcCh2ZnNwLT52ZmNfbmFtZSwgZnNfbmFtZSkgPT0gMCkgeworCQkJ CQl0ZC0+dGRfcmV0dmFsWzBdID0gaW5kZXg7CisJCQkJCWJyZWFrOworCQkJCX0gZWxzZQorCQkJ CQlpbmRleCsrOworCQkJaWYgKCF2ZnNwKQorCQkJCXJldHVybiAoRUlOVkFMKTsKKwkJCWJyZWFr OworCisJCS8qCisJCSAqIFRyYW5zbGF0ZSB0aGUgZmlsZS1zeXN0ZW0gdHlwZSBpbmRleCBpbnRv IGEKKwkJICogbnVsbC10ZXJtaW5hdGVkIGZpbGVzeXN0ZW0gaWRlbnRpZmllciBzdHJpbmcuCisJ CSAqLworCQljYXNlIExJTlVYX0dFVEZTVFlQOgorCQkJaW5kZXggPSBhcmdzLT5hcmcxOworCisJ CQlUQUlMUV9GT1JFQUNIKHZmc3AsICZ2ZnNjb25mLCB2ZmNfbGlzdCkKKwkJCQlpZiAoaW5kZXgt LSA8PSAwKQorCQkJCQlicmVhazsKKwkJCWlmICghdmZzcCkKKwkJCQlyZXR1cm4gKEVJTlZBTCk7 CisKKwkJCXN0cmxjcHkoZnNfbmFtZSwgdmZzcC0+dmZjX25hbWUsIHNpemVvZihmc19uYW1lKSk7 CisJCQlic2QybGludXhfZnNuYW1lKGZzX25hbWUpOworCisJCQkvKgorCQkJICogV2UgYXNzdW1l IHRoYXQgdGhlIGJ1ZmZlciBwb2ludGVkIHRvIGJ5CisJCQkgKiAodm9pZCAqKShyZWdpc3Rlcl90 KWFyZ3MtPmFyZzIgaXMgZ3JlYXRlciB0aGFuIE1GU05BTUVMRU4KKwkJCSAqLworCQkJZXJyb3Ig PSBjb3B5b3V0KGZzX25hbWUsICh2b2lkICopKHJlZ2lzdGVyX3QpYXJncy0+YXJnMiwKKwkJCQkJ TUZTTkFNRUxFTik7CisJCQlicmVhazsKKworCQkvKgorCQkgKiBSZXR1cm4gdGhlIHRvdGFsIG51 bWJlciBvZiBmaWxlIHN5c3RlbSB0eXBlcworCQkgKiBjdXJyZW50bHkgcHJlc2VudCBpbiB0aGUg a2VybmVsLgorCQkgKi8KKwkJY2FzZSBMSU5VWF9HRVRORlNUWVA6CisJCQlUQUlMUV9GT1JFQUNI KHZmc3AsICZ2ZnNjb25mLCB2ZmNfbGlzdCkKKwkJCQlpbmRleCsrOworCQkJdGQtPnRkX3JldHZh bFswXSA9IGluZGV4OworCQkJYnJlYWs7CisKKwkJLyogSW52YWxpZCBvcHRpb24gcGFzc2VkICov CisJCWRlZmF1bHQ6CisJCQllcnJvciA9IEVJTlZBTDsKKwl9CisJcmV0dXJuIChlcnJvcik7Cit9 Cg== ------=_Part_63956_28802723.1169855433358-- From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 27 15:25:33 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 222A016A403 for ; Sat, 27 Jan 2007 15:25:33 +0000 (UTC) (envelope-from vsprajan@yahoo.com) Received: from web52008.mail.yahoo.com (web52008.mail.yahoo.com [206.190.48.91]) by mx1.freebsd.org (Postfix) with SMTP id B2D4D13C48C for ; Sat, 27 Jan 2007 15:25:32 +0000 (UTC) (envelope-from vsprajan@yahoo.com) Received: (qmail 71892 invoked by uid 60001); 27 Jan 2007 14:58:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=fKp1pICmCWAIDVV5Zv/KLhKc4AL3t/+gYtR1WokMsQOvTWOG6QO+7S2Xz8S4pK1qaDzLz16v8MZq4rws9qFyS9tVm4nAS0lqa/jQG1yXSY34pTUJhMQn8jSi/8CRJaBJvNwOMA4qF9PCaGDZYRjc8TB62PZGt2hBK7e9NS11qPY=; X-YMail-OSG: 5kV0GR4VM1msxEQ.LO.vExm_XxHzvYlmBTqlfDhOIG_0yO8tjWusBjsZOABksbEvmLOdvQhf4Rvs68ng67.9BrdDpD7U28t7kJ6L9Lo4QAHDTAEBxEWQEJgV_wgabp11XwHURjHgdZgTnpPLokBSRLwXdTmUwtG688FIUU0.oLrQV5LwWmb1EJEcDGs- Received: from [210.212.103.32] by web52008.mail.yahoo.com via HTTP; Sat, 27 Jan 2007 06:58:51 PST Date: Sat, 27 Jan 2007 06:58:51 -0800 (PST) From: "V.S.Prasanna Rajan" To: freebsd-emulation@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <690901.52680.qm@web52008.mail.yahoo.com> X-Mailman-Approved-At: Sat, 27 Jan 2007 19:12:22 +0000 Subject: Virtual Machine software for Free BSD-Help requested 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: Sat, 27 Jan 2007 15:25:33 -0000 Dear All, With ref to the subject mentioned above please suggest me a web site where I can download the files for the same. I am running a FreeBSD 6.2 based (Intel-processor) PC. I want to install MS windows as a guest operating system through Virtual Machine . Awaiting kind reply in this regard. with regards, Rajan. Dr. V.S. Prasanna Rajan,Scientist Fellow,Gyrotron Project,MWT Area,CEERIPilani - 333031, Rajasthan,INDIA.Phone: Office: +91-(0)1596-252233Mobile: 9413076790Timings: Monday to Friday 9.00 am to 1.00 pm & 2.00 pm to 6.00 pm ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index From owner-freebsd-emulation@FreeBSD.ORG Sat Jan 27 19:48:17 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0CA216A406 for ; Sat, 27 Jan 2007 19:48:17 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id A5DE813C48A for ; Sat, 27 Jan 2007 19:48:17 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l0RJJ9Op019197; Sat, 27 Jan 2007 13:19:09 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45BBA5A9.1040100@freebsd.org> Date: Sat, 27 Jan 2007 13:19:05 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070121) MIME-Version: 1.0 To: "V.S.Prasanna Rajan" References: <690901.52680.qm@web52008.mail.yahoo.com> In-Reply-To: <690901.52680.qm@web52008.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2493/Fri Jan 26 06:00:46 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-emulation@freebsd.org Subject: Re: Virtual Machine software for Free BSD-Help requested 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: Sat, 27 Jan 2007 19:48:17 -0000 On 01/27/07 08:58, V.S.Prasanna Rajan wrote: > > Dear All, > With ref to the subject mentioned above please > suggest me a web site where I can download the > files for the same. I am running a FreeBSD 6.2 > based (Intel-processor) PC. I want to install MS > windows as a guest operating system through Virtual > Machine . Awaiting kind reply in this regard. > with regards, > Rajan. Search for qemu and bochs in the ports collection. Eric