From owner-freebsd-ppc@FreeBSD.ORG Fri Sep 1 19:11:39 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 EE95B16A4DD; Fri, 1 Sep 2006 19:11:39 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B7EF43D64; Fri, 1 Sep 2006 19:11:35 +0000 (GMT) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id k81JBYpc011463; Fri, 1 Sep 2006 12:11:34 -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/smtpin02/MantshX 4.0) with ESMTP id k81JBVfH024364 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Sep 2006 12:11:33 -0700 (PDT) In-Reply-To: <49A44B45-780B-462D-AB1E-547E87460208@mac.com> References: <933C0437-DDF8-4A61-83BA-F4920D9E6E96@mac.com> <44F87E8C.9000705@freebsd.org> <49A44B45-780B-462D-AB1E-547E87460208@mac.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <769A17D5-FD72-417F-8F0C-C371148296D9@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 1 Sep 2006 12:10:54 -0700 To: Marcel Moolenaar X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAgNsLY8DbC8F X-SpamScan: Suspected Spam Cc: ppc@freebsd.org, Peter Grehan 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 19:11:40 -0000 On Sep 1, 2006, at 11:44 AM, Marcel Moolenaar wrote: > On Sep 1, 2006, at 11:40 AM, Peter Grehan wrote: > >>> 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 :-/ I found it! The ucontext on powerpc is 16-bytes aligned. This means that struct tcb is a multiple of 16-bytes. It so happened that there were 8 bytes of padding after struct ppc32_tp. So, we need to force 16-byte alignment for struct ppc32_tp or add internal padding before struct tcb so as to eliminate padding after it. I opted for the latter... All is well! -- Marcel Moolenaar xcllnt@mac.com