From owner-freebsd-ppc@freebsd.org Mon Oct 22 21:35:41 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCD32FD7D1A; Mon, 22 Oct 2018 21:35:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4174B7579C; Mon, 22 Oct 2018 21:35:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id BDA6710AFCD; Mon, 22 Oct 2018 17:35:38 -0400 (EDT) Subject: Re: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of To: Mark Millard , FreeBSD Toolchain , Sean Fertile References: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML From: John Baldwin Message-ID: Date: Mon, 22 Oct 2018 14:35:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 22 Oct 2018 17:35:39 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 21:35:41 -0000 On 10/19/18 7:23 AM, Mark Millard wrote: > [I'm adding toolchain and John B. to the TO: list. John B. > may want to reply to Sean F. I'm also adding a > /lib/libgcc_s.so related item to the list of 3 known > issues.] > >> On 2018-Oct-19, at 6:21 AM, Sean Fertile wrote: >> >> Clang isn't getting the tls model wrong, it actually generates pic code by default as if -fpic were specified. I think the original intent behind switching >> to pic by default was due to incorrectly thinking gcc was pic by default (I'm not sure if this was meant as only gcc on BSD or gcc on powerpc64 in general), >> as well as working around some problems that clangs non-pic codegen has/had for the ELF V1 abi. There are some patches on phabricator for switching >> the default back to non-pic codegen, but they leave the pic default for BSD: https://reviews.llvm.org/D53384 and https://reviews.llvm.org/D53383 >> >> According to what you and John are saying the pic default is incorrect for BSD as well. If thats the case please either comment on the reviews to let Stefan know, >> or let me know here and we can update the patches accordingly. No, what I am saying is that in GCC, the decision for dynamic TLS model vs static TLS model is based on whether or not -fPIC is explicitly given on the command line. For MIPS at least (where I am familiar with this), both GCC and clang default to implicit PIC. However, GCC uses static TLS models (initial-exec, etc.) when -fPIC isn't given on the command line even if PIC is still implicitly enabled. It only uses the dynamic TLS models (intended for use in shared libraries) if -fPIC is explicitly passed on the command line. However, clang implements implicit PIC by passing the equivalent of -fPIC to the llvm backend, so on MIPS at least, the result is that llvm _always_ uses the dynamic TLS models including for static libraries and binaries where this is wrong. I have some patches from one of the LLVM MIPS folks that kind of hackishly fix this, but by adding a new flag only for MIPS. I wanted to adjust their patches to be more generic so that there's a new '-mshared-library' or some such passed from clang to llvm and have clang only set that to true if -fPIC is explicitly given on the command line to match GCC's behavior. So to be clear, this isn't saying that the implicit PIC setting is wrong. It is saying that the llvm backend incorrectly interprets the clang front-end's implicit PIC setting as being an explicit PIC setting for the purposes of choosing the TLS model to use. -- John Baldwin