Date: Mon, 22 Oct 2018 14:35:37 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Sean Fertile <sd.fertile@gmail.com> Cc: Justin Hibbits <chmeeedalf@gmail.com>, Nathan Whitehorn <nwhitehorn@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of Message-ID: <e4ec4698-ffed-f0c6-c36d-4b3abea8a66c@FreeBSD.org> In-Reply-To: <CF792C64-96D5-4C64-BEAA-D5878C96021C@yahoo.com> References: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> <CA%2BD7ZeEwOnshEmnRepH6_y3ns2bF859k5i-1fEspYwt0mWJ_gg@mail.gmail.com> <CF792C64-96D5-4C64-BEAA-D5878C96021C@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <sd.fertile at gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e4ec4698-ffed-f0c6-c36d-4b3abea8a66c>