From owner-freebsd-ppc@FreeBSD.ORG Fri Sep 1 18:45:36 2006 Return-Path: X-Original-To: ppc@freebsd.org Delivered-To: freebsd-ppc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BD9A16A4DE; Fri, 1 Sep 2006 18:45:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6D6B43D55; Fri, 1 Sep 2006 18:45:35 +0000 (GMT) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id k81IjZO1008992; Fri, 1 Sep 2006 11:45:35 -0700 (PDT) Received: from [192.168.1.5] (c-67-164-11-148.hsd1.ca.comcast.net [67.164.11.148]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id k81IjQPH014976 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Sep 2006 11:45:33 -0700 (PDT) In-Reply-To: <44F87E8C.9000705@freebsd.org> References: <933C0437-DDF8-4A61-83BA-F4920D9E6E96@mac.com> <44F87E8C.9000705@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49A44B45-780B-462D-AB1E-547E87460208@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 1 Sep 2006 11:44:49 -0700 To: Peter Grehan X-Mailer: Apple Mail (2.752.2) Cc: ppc@freebsd.org Subject: Re: Status of threading and TLS X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 18:45:36 -0000 On Sep 1, 2006, at 11:40 AM, Peter Grehan wrote: > Hi Marcel, > >> If anyone has any suggestions why for libpthread we end up >> with r2 off by 8 bytes, I'm happy to hear it... > > I don't have access to a PPC machine at the moment, but would it > have anything to do with: > > struct ppc32_tp { > void *tp_dtv; /* dynamic thread vector */ > uint32_t _reserved_; > double tp_tls[0]; /* static TLS */ > }; > > I think the last element was put in for alignment, but would that > possibly have an effect somewhere else, in that it's forcing an 8- > byte pad somewhere ? I've been thinking about that too. I played with the following definition to see if it made a difference: union ppc32_tp { void *tp_ptr[2]; double _align_; }; It didn't make a difference :-/ Note that I use the same on ia64, except that on ia64 we need it aligned on a 16-byte boundary. Hence, the definition is: struct ia64_tp { void *tp_dtv; uint64_t _reserved_; long double tp_tls[0]; } It doesn't cause problems on ia64... -- Marcel Moolenaar xcllnt@mac.com