From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HeFxI-0007lU-Ut for qemu-devel@nongnu.org; Wed, 18 Apr 2007 15:36:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HeFxI-0007lG-FH for qemu-devel@nongnu.org; Wed, 18 Apr 2007 15:36:40 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HeFxI-0007lD-88 for qemu-devel@nongnu.org; Wed, 18 Apr 2007 15:36:40 -0400 Received: from grayson.netsweng.com ([207.235.77.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HeFsQ-00071K-1D for qemu-devel@nongnu.org; Wed, 18 Apr 2007 15:31:38 -0400 Received: from amavis by grayson.netsweng.com with scanned-ok (Exim 3.36 #1 (Debian)) id 1HeFsP-0006ZQ-00 for ; Wed, 18 Apr 2007 15:31:37 -0400 Received: from grayson.netsweng.com ([127.0.0.1]) by localhost (grayson.netsweng.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri1EuPvteKwx for ; Wed, 18 Apr 2007 15:31:18 -0400 (EDT) Received: from h211.241.141.67.ip.alltel.net ([67.141.241.211] helo=trantor.stuart.netsweng.com) by grayson.netsweng.com with esmtp (Exim 3.36 #1 (Debian)) id 1HeFs5-0006ZE-00 for ; Wed, 18 Apr 2007 15:31:18 -0400 Date: Wed, 18 Apr 2007 15:30:56 -0400 (EDT) From: Stuart Anderson Subject: Re: [Qemu-devel] linux-user target In-Reply-To: <1176921819.6333.85.camel@rapid> Message-ID: References: <1176228712.22569.27.camel@jma4.dev.netgem.com> <1176921819.6333.85.camel@rapid> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, 18 Apr 2007, J. Mayer wrote: > You're right: I think all TLS specific code is located in the glibc. In my last tracing through qemu.log, I did check for r2 references, and there was one store near the beginning that looked like what glibc would do (r2 = ptr+0x700), and the rest of the access were reads of r2. > It may be related to some of the library versions installed in > your 64 bits environment that would not be the same as the one used in > the 32 bits environment. Both are current Debian etch systems, a real x86_64, and a real x86. Both are running the same library versions. ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries > One important > precision that may make a big difference: I always use gcc 3.4 to > compile because I know several gcc 4.x bugs (crash during ISO C > compliant code and/or incorrect generated asm instructions), then I do > not consider gcc 4.x as usable for a production environment today. I'm using gcc-3.4 as well. ii gcc-3.4 3.4.6-5 The GNU C compiler ii gcc-3.4-base 3.4.6-5 The GNU Compiler Collection (base package) Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149