From owner-freebsd-arch@FreeBSD.ORG Fri Apr 6 19:19:00 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1F4F106566C for ; Fri, 6 Apr 2012 19:19:00 +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 61E358FC0A for ; Fri, 6 Apr 2012 19:19:00 +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 1SGEgE-000CIo-6l; Fri, 06 Apr 2012 12:18:42 -0700 Message-ID: <4F7F4198.2010705@bluezbox.com> Date: Fri, 06 Apr 2012 12:18:48 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <2FF97057-905D-4F02-9138-75680ABC6202@canonware.com> <4F79F020.9070504@freebsd.org> <3C11DB18-1C43-446E-A0BC-FC15C6126819@canonware.com> <4F7A170E.8020209@bluezbox.com> <4F7B98C0.6090209@bluezbox.com> <20120405205822.GR9275@thebe.jupiter.sigsegv.be> <3F19C7EF-86D8-4165-AAF1-91424A518333@canonware.com> In-Reply-To: <3F19C7EF-86D8-4165-AAF1-91424A518333@canonware.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 06/04/2012 12:09 PM, Jason Evans wrote: > On Apr 5, 2012, at 1:58 PM, Kristof Provost wrote: >> On 2012-04-04 22:00:57 (-0700), Jason Evans wrote: >>> On Apr 3, 2012, at 5:41 PM, Oleksandr Tymoshenko wrote: >>>> I tested it for MIPS - works fine. Unfortunately I don't have >>>> ARM hardware that works with HEAD so can't test ARM part of the change. >>> >>> Thanks for testing MIPS. I'm going to just assume that TLS works everywhere. >>> If it doesn't, we'll find out soon enough. =) >>> >> It appears to be rather broken on ARM, at least in combination with >> shared libraries. >> >> […] > > > Thanks for testing, Kristof. It's good to know that there are problems on ARM, but now I'm not sure what to do about committing the updated malloc. I don't have the time or the hardware to make TLS reliable on ARM. Do I commit the malloc patch and let someone who cares about ARM fix TLS after the fact? Or do I wait an indefinite amount of time to let solid TLS support materialize? [...] 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] Cc: Kristof Provost , Jason Evans Subject: Re: TLS on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:19:00 -0000 On 06/04/2012 12:09 PM, Jason Evans wrote: > On Apr 5, 2012, at 1:58 PM, Kristof Provost wrote: >> On 2012-04-04 22:00:57 (-0700), Jason Evans wrote: >>> On Apr 3, 2012, at 5:41 PM, Oleksandr Tymoshenko wrote: >>>> I tested it for MIPS - works fine. Unfortunately I don't have >>>> ARM hardware that works with HEAD so can't test ARM part of the change. >>> >>> Thanks for testing MIPS. I'm going to just assume that TLS works everywhere. >>> If it doesn't, we'll find out soon enough. =) >>> >> It appears to be rather broken on ARM, at least in combination with >> shared libraries. >> >> […] > > > Thanks for testing, Kristof. It's good to know that there are problems on ARM, but now I'm not sure what to do about committing the updated malloc. I don't have the time or the hardware to make TLS reliable on ARM. Do I commit the malloc patch and let someone who cares about ARM fix TLS after the fact? Or do I wait an indefinite amount of time to let solid TLS support materialize? I'm working on this issue. I hope it will be resolved in a matter of days.