From owner-freebsd-ppc@freebsd.org Fri Oct 19 14:24:08 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 B123AFCC589 for ; Fri, 19 Oct 2018 14:24:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 30FF27FB6B for ; Fri, 19 Oct 2018 14:24:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ewG4AaQVM1le_Na5WyFyc4r2ZasJex5h02tBMDdIKY8pzw9tqTd2piO7Pia2umx o0lQhMXqQhpP8NtNKgv4Hzr.Ad9MJ1JPHF46uiXflGaf.9V.MwRNypdZWw5cP0tUJPBOoA7EUeuG aBX1dBnEycVBSum3u41uJA.WzGFD2FHSqtQi4QsiukWj8DpRswGK5t5YAYi_8sJyKqwSntNhCWTd Xra8aNjbQMU0elIlTvJQT4Sont3zfLpmWvsAtc1juKWwZUXP8ROSFUe0OxpVSuOxsKXxSXrcuH7J 5z8ehYKSjgPjoKlM2QpXQax3lRyxTzfDjK6F5iEuFVm.GeOF9mcmVOk81EysO93jyF9BEvCgokpF 9K_sFCeft.uBMGzlwm.aT3NGBn1uUGMUHttNvsM_DMu2aaX4c3kyFwDhs2L.dGv2o55lWywMYI7I MZoc5.p52QfLB2eObJvUvUiwTquT9XC4DrPzfH91xwe1eiSGO9EKzeVNa8cY6535qj_4Hh3gZXoc a02mnMbrNbSpAewF.FY8PlrZw.o4zEU9IzopE5avosxNwKhoyCaESLRydWooakWMZ7pQGF.wIx5N i0FhIhuOtJ6Hp.PdapwO6OAkogoPkRgdvTVwyqef5y8XJkDcCmEN2.t3ZckQh572a_mWyC8r1m23 tREfVXHUcILat1EUVDTu7o0e.AKtjGsCVZkgkBmE7cg3m5i3sqKtNTYFc1ZBnhiYiAC_THf2OetP rF1Ir57gC2nRE86qoFj1Pw5GDn7qUnJlUrfJ8msJVaklVLfJafpJykb8ohWrFzj9M8IzHOYwhWuv bUgWyQ5Dc1Bkio0IoI2iKIClXQA._pZbnDg320_va4f4vM_PWrRg5VWQ_3YDttJSLakonP.HV5eb r1D1nl0o4L7SYEPxt6uwBWVwd6OJ25uSb.3ARUhRf3RZNE3ezm8AeVr0YhT2DUXowGmd1KHEK.pM x._Krn3jmXkQRWCv7erdygkyefPNQoJzoanmeNHjkXsCFV11fHwkpkMCAg20W9zraQcW.OkcStd7 7CYvSD7t.iqJTBF6GExPN5uE7YvfLMjDn6dppY57PNGF_PQHRKo5OMaeTKtWeuCLBADu_haJXVEz bHrzdvdBMSfb7lpo2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Oct 2018 14:24: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.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c0028b0ff7bfa6ae4a2e6ebce2d16d60; Fri, 19 Oct 2018 14:23:59 +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: Fri, 19 Oct 2018 07:23:58 -0700 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> To: FreeBSD Toolchain , John Baldwin , 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: Fri, 19 Oct 2018 14:24:08 -0000 [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: >=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 > Thanks > Sean >=20 >=20 >=20 >> On Thu, Oct 18, 2018 at 11:27 AM Mark Millard via freebsd-ppc = wrote: >> I described to John Baldwin what I know of for why clang is >> not yet appropriate to buildworld buildkernel for powerpc64 >> and powerpc: >>=20 >> QUOTE >> Unfortunately, clang is broken in other ways for buildworld >> buildkernel use for targeting powerpc64 or powerpc: >>=20 >> A) it silently ignores __builtin_eh_return(offset,handler) >> and so produces system-library code that is broken >> relative to handling thrown C++ exceptions. >>=20 >> B) it produces types of linkage for buildkernel that >> FreeBSD does not handle, leading to dynamic loads >> of .ko files that crash the system. (Back in clang >> 4 days it did not have this problem and I was >> running kernels built by clang.) >> END QUOTE >>=20 >> John Baldwin reported back something of which I was unaware: >>=20 >> QUOTE >> It will also get the TLS model wrong for powerpc. Both MIPS and = powerpc >> have an implicit default to PIC mode and llvm interprets this = implicit >> PIC to mean that it should use dynamic TLS models (intended for use = in >> shared libraries) always. GCC only uses dynamic models if -fPIC is >> explicitly passed on the command line. I have a hack to force the = TLS model >> for static libraries and binaries for MIPS in bsd.*.mk that isn't = in-tree, >> but it really needs to be fixed in clang and llvm. >> END QUOTE >>=20 >> I wonder if there is anything in llvm's bugzilla about this, or >> FreeBSD's bugzilla for that matter. >>=20 >> Are there other known issues not covered by the above 3? >>=20 One other item that I should have mentioned (so 4 overall): /lib/libgcc_s.so does not push and pop the CFA (Cannonical Frame Address) information during DW_CFA_remember_state and DW_CFA_restore_state and so _Unwind_RaiseException can end up stuck looping looking at the same frame over and over when the compiler happens to generate these: The default stack register plus an offset of 0 ends up being used as the CFA rule. Other register information tends to be defined relative to the CFA. clang does generate DW_CFA_remember_state and DW_CFA_restore_state in some contexts. Some of the /usr/tests/Kyuafile tests for use with devel/kyua timeout this way and so end up as classified as broken (instead of as failed). If llvm's libunwind were made to work for FreeBSD's powerpc family ABIs , then switching to it would be one way to fix this. llvm's libunwind currently fails to compile for FreeBSD. One reason is it uses Darwin specific powerpc family assembler notation in a .S file (for example, lack of % before rN register notation). Another reason is the .S file in question requires the C preprocessor to be run on it to select the right code for the architecture but FreeBSD doe not do so when targeting powerpc64 (or, likely, powerpc). I do not claim that is all there may be to getting llvm's libunwind working for powerpc64 and powerpc FreeBSD. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)