From owner-freebsd-mips@FreeBSD.ORG Thu Feb 9 22:41:11 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A7CD106564A for ; Thu, 9 Feb 2012 22:41:11 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 21AF38FC08 for ; Thu, 9 Feb 2012 22:41:10 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Rvcfo-000HcV-Dn; Thu, 09 Feb 2012 14:41:05 -0800 Message-ID: <4F344B84.4040107@freebsd.org> Date: Thu, 09 Feb 2012 14:41:08 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Robert Millan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 08/12/2010 8:34 AM, Robert Millan wrote: > This patch implements support for retrieving the TLS pointer via RDHWR > instruction. > > It is implemented through emulation for platforms that don't provide > this instruction natively (such as gxemul/malta). Platforms that do > provide it would need a separate patch. > > Reading register $29 with RDHWR is becoming the de-facto standard to > implement TLS. According to linux-mips wiki, MIPS Technologies has > reserved hardware register $29 for ABI use. Furthermore current GCC [1] > makes the following assumptions: > - RDHWR is natively available or otherwise emulated by the kernel > - Register $29 holds the TLS pointer > > [1] gcc-4.4.4/gcc/config/mips/mips.md reads: > > ; ; The TLS base pointer is accessed via "rdhwr $3, $29". No current > ; ; MIPS architecture defines this register, and no current > ; ; implementation provides it; instead, any OS which supports TLS is > ; ; expected to trap and emulate this instruction. rdhwr is part of the > ; ; MIPS 32r2 specification, but we use it on any architecture because > ;; we expect it to be emulated. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list Cc: freebsd-mips@freebsd.org Subject: Re: [PATCH] Retrieval of TLS pointer via RDHWR X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:41:11 -0000 On 08/12/2010 8:34 AM, Robert Millan wrote: > This patch implements support for retrieving the TLS pointer via RDHWR > instruction. > > It is implemented through emulation for platforms that don't provide > this instruction natively (such as gxemul/malta). Platforms that do > provide it would need a separate patch. > > Reading register $29 with RDHWR is becoming the de-facto standard to > implement TLS. According to linux-mips wiki, MIPS Technologies has > reserved hardware register $29 for ABI use. Furthermore current GCC [1] > makes the following assumptions: > - RDHWR is natively available or otherwise emulated by the kernel > - Register $29 holds the TLS pointer > > [1] gcc-4.4.4/gcc/config/mips/mips.md reads: > > ;; The TLS base pointer is accessed via "rdhwr $3, $29". No current > ;; MIPS architecture defines this register, and no current > ;; implementation provides it; instead, any OS which supports TLS is > ;; expected to trap and emulate this instruction. rdhwr is part of the > ;; MIPS 32r2 specification, but we use it on any architecture because > ;; we expect it to be emulated. Hi Robert, It's a shame that it took a year to commit this patch :( but finally it made it to SVN. I modified it a little bit to be more universal and MIPS64-compatible.