From owner-freebsd-ppc@freebsd.org Tue Oct 23 21:15:09 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 05B00FFD1B0 for ; Tue, 23 Oct 2018 21:15:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-22.consmr.mail.ne1.yahoo.com (sonic304-22.consmr.mail.ne1.yahoo.com [66.163.191.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9262170BBD for ; Tue, 23 Oct 2018 21:15:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YCcHGaoVM1lXw9D9t78UlsECVl173YrkE0iHZihgZsKe9HPii4qsJimayYMupAB pPHnD6FLxiWgCRlECgLFk4vXNzd8.JGozzRXKoYlCIWIBixlPEb0ccAELX.cEGPMnoxVC_PZ8qiG d0xRKz4pt9fMfsVPkLfOQvjIvb_L0BZTTsMj3eCgRMk3E5Sfehwe1ZuCh1iY.tvUBZA7260V0ubB RXmuTI9Qoc.0BYMEZnEoQYS2bwVOQD4iiCRopVg40G.YG_CuqqVEsyCVAnjSzvs2rbks4wOPBh_G _w9g6btZmxDE0gXWUAv55mXsKHPBBGxudSsao.pa.D4SclWK7S2YiLjXHH.d2w3J8KhXORRWw4bX fr1RdGbDsruW32ZxUizI1K.tAGz4NzsQUcbVOPP8uGc43fqaXQaSeuiZT3iaj2c3wcxD80g5bXYP OvceoOnUMpLXg8ZqiBWyw3gW895WvihBNGpMMisDfQTdsGDZkR2K3POm21VMsN2szqRCviA1ZvfM HnfoS3B._Yz2WjxbtIhFcASKD4HJT3QFP.Qy.Qxzu4FPL_1TOooDtl2xioRODgjR9i_4JXhdgw8v NaKwoDfcNxcgslc1mJgIeUnaXzlxRnNI22WSAqryzuNKlb6KA2kDoMl13WveThs.zBX8HP3GMQh1 RSj4Jm08leN8TV4MRvh3r8VHisYGLltQvxlwJJFCbQRmgthNOoWRRlkPxYb4gNTOXifkpjFWzxwN GKIT.VzFxycd2k9E93V7vTgMcYF77.uwXtNcuBRpqA2KTU96lFszckhsmzCiJWzdPUlC_xemnHuT gIK6Oc93Lv7dHBw_Ek5bWB2nJQXQowwbCZ7cCQX8dlq_3i7rGOK4au50Wbym4t4RLQG1yb1BPUfm RFzazHnZ_ToLVHXmdby3ukXydP0reYAfKOoLnvgimVNvHeMn6DXgCZenz5FMe5OZ2Lfp0bdl1zkY Ywxc3ZProbTyVzDsSDMSDr6rSAADYv6K0hTwwCKaWJBdEE4nkChaSsRAvBOdoNHoN_PT1szysV30 DcFNmsjTZKWoJ2.VLgEQ.E7bRzUDZ4yOm.g3Q4JVFLg1ezQhsHOuXee13KHE1Djetu6yr3NjCD9S fJ41YEok- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Tue, 23 Oct 2018 21:15:00 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp413.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0aa92ced50a486c022d21f2e083dfa26; Tue, 23 Oct 2018 21:14:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of From: Mark Millard In-Reply-To: Date: Tue, 23 Oct 2018 14:14:56 -0700 Cc: FreeBSD Toolchain , Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: References: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> To: Sean Fertile X-Mailer: Apple Mail (2.3445.9.1) 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: Tue, 23 Oct 2018 21:15:09 -0000 [Mostly just giving some powerpc64 detail, at least when base/binutils is used.] On 2018-Oct-22, at 2:35 PM, John Baldwin wrote: > 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.] >>=20 >>> On 2018-Oct-19, at 6:21 AM, Sean Fertile = wrote: >>>=20 >>> 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=20 >>> 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),=20 >>> 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 >>>=20 >>> 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. >=20 > 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. FYI: John discovered that mips64/powerpc64 is the context for PIC being the default for clang (I'm ignoring x86_64, Windows, MachO and MacOSX in my comments): bool Generic_GCC::isPICDefault() const { switch (getArch()) { case llvm::Triple::x86_64: return getTriple().isOSWindows(); case llvm::Triple::ppc64: case llvm::Triple::ppc64le: return !getTriple().isOSBinFormatMachO() && !getTriple().isMacOSX(); case llvm::Triple::mips64: case llvm::Triple::mips64el: return true; default: return false; } } > 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. >=20 > 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. For powerpc64 things are somewhat different via some link-time optimizations when base/binutils is in use (lld not being ready for use for powerpc64 as I understand). (I've no clue what would happen with lld.) cc -g -O2 -c will produce .o files with the __tls_get_addr calls, for example (source shown later): # objdump -r tlsy.o | grep __tls_get_addr 0000000000000024 R_PPC64_REL24 __tls_get_addr 0000000000000038 R_PPC64_REL24 __tls_get_addr # objdump -r tls_main.o | grep __tls_get_addr 0000000000000020 R_PPC64_REL24 __tls_get_addr 0000000000000034 R_PPC64_REL24 __tls_get_addr 000000000000008c R_PPC64_REL24 __tls_get_addr 00000000000000a0 R_PPC64_REL24 __tls_get_addr This is as John indicated. But the likes of: # cc -g -O0 tls_main.o tlsy.o tls.o ends up with a.out having r13 use and no such subroutine calls to __tls_get_addr in x, y, or main. There are some nop instructions from where substitutions were made. It appears that mips64 does not have such a late-optimization in John's context: the __tls_get_addr use survives into a.out as I understand. The source for the example used above was: # more tls.c int __thread i =3D 3; int __thread j =3D 2; # more tlsy.c extern int __thread i; extern int __thread j; int y() { return i+j; } # more tls_main.c extern int __thread i; extern int __thread j; extern int y(); int x() { return i+j; } int main () { return x()-y(); } (So main got some inlining of x() in order for the tls_main.o to show 4 R_PPC64_REL24 uses for __tls_get_addr .) I have no clue if the late-optimization for powerpc64 covers all the cases where direct use of some static TLS model would be appropriate. I just know that, at least in some types of contexts, some calls to __tls_get_addr are eliminated at link time when base/binutils is in use. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)