From owner-freebsd-toolchain@freebsd.org Sun Oct 14 02:40:49 2018 Return-Path: Delivered-To: freebsd-toolchain@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 8A11110BFB00 for ; Sun, 14 Oct 2018 02:40:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 15B3B74366 for ; Sun, 14 Oct 2018 02:40:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 9YiVoOsVM1ntt8ENEDTYm.CzlPxc0qDAo4Wb2s0bot_MXS5wL8O0fQBI1_dclno Y3K7EdtcJMJkjoikYU4OJRkwYzuKLsfQTHOG3urRhz95AnEbqOeQ5QchMR0vqlahWVW0g9cpkatG Ztikl1mATAtCci.GLWWmtsI_mDnh3CNwoRPnMynno1xdgYCYkLVEjmUdP06snASmVoKyErZy6orY f6QpMbG6IjvzNAiK8v.fusysVqedSnxHpcS5_soypYoLozcLEVP301jOmotTm2J5a.O2c_Km7x89 C7ZjZrUEfIyHR3l.94h77rCxsms6qTbFfQo68gwESsg3mQSvDaHo.IN9dwp3qvACFT7M9o4bsK3o WTvFGv7mm0g0sfvTOl0yC024zsr5q6.grQ7cYxo93doxAKMaAIe11ZxJO5XGWHxWX93fs45QQWMw ojYSNEHAl_yDcmCBaE.02ILbMkvWLCb3L_AQN2b_TmD.CFyh6ZbrZYMqULdjAsJ8LpEHdAMngQ_A 3gGFuSlNVsC1YcHANmbB4C7cPcRJaAtjN7jVwBCAhC6vLnSDMPh7bd1SdHFuuU1PDbPfK6tbLkRd VXGmkx3C00tYE9FHzQXRlY_oWrqNPuBtkWfj2cX4m2Gr990Il1I2wsHVNDWafywdGvGb_OngLe5Q vDAobmHoXt1Mnkl4cNM7W93sZIvi8IEkNrFX85t_2Mkz6NPeJ_iSbiho6AKMhHVNWeCJ86anhzNu rTqeWxRTDg.stUwaCTuEXvKdjAX.eaM.8wcvCW2D1SuXuCuDB3W8ZPcdJs8hyOKeNM20HGv1fgK9 5zSABX_OGmk9vWyA4g4Bo8f7L2Jl3xQq_hqLI2hXQBX5BnDlaAxd3Hv3NuUj.mQCiAikb59hU3o0 mJKQOWh_UIf642TE0igVFYs.8GM2lbztydOawvQKcDE.4Gtb03QPYMJNWnMu2SbIoRuQwO0CIv3n y9RDscv9UXBlMzOuknikqLwKWPiQjg_6pQ8gWbOB6xJkYDK5kPJMrXTHKLVGUD1pVO2n8jO44F7V ArKdl.w4nrgHpFCLRZtuqcLPJ049Jh3Z4YapcNgN14woizwwZuCwBM5xWan0euWWT4.cbBs8ny09 q_dAEwQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 Oct 2018 02:40:47 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3598d8044ca8e133d087ea983e959340; Sun, 14 Oct 2018 02:40:47 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: GPL requirements vs. "some of which are compiled with GCC" terms in special exceptions? From: Mark Millard In-Reply-To: <61B6C299-2F93-4678-8928-3CABDFED6623@FreeBSD.org> Date: Sat, 13 Oct 2018 19:40:46 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <5449BAA6-E022-4DE4-870A-8AE132A6F9FA@yahoo.com> <61B6C299-2F93-4678-8928-3CABDFED6623@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 02:40:49 -0000 On 2018-Oct-13, at 10:15 AM, David Chisnall = wrote: > This is a known problem with the GCC runtime libraries. GCC 4.3 and = later have a much better exemption (which talks about any eligible = compilation process, rather than being compiled with GCC), but those are = GPLv3 and so unacceptable for FreeBSD. I see. Good to know. > I don=E2=80=99t believe that we are using any of those files on = platforms where clang is the default system compiler. LLVM=E2=80=99s = libUnwind should be able to handle PowerPC on Linux, so it=E2=80=99s = worth checking if this is the case on FreeBSD. Last I tried llvm's libunwind for powerpc64 was back in = 2016-Dec/2017-Jan. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 . There = was also the llvm submittal 31590. I might try it again at some point. But clang and llvm have other issues = for use for buildworld buildkernel as well as I understand. (But I'm doing = some new experiments these days.) I've no clue if llvm's libunwind is intended to be compliant with the powerpc64 and powerpc ABIs that FreeBSD bases itself on for the powerpc family. >> On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain = wrote: >>=20 >> While investigating powerpc64 C++ exception handling for >> builds under devel/powerpc64-gcc I ran into the following >> in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c : >>=20 >> /* As a special exception, if you link this library with other files, >> some of which are compiled with GCC, to produce an executable, >> this library does not by itself cause the resulting executable >> to be covered by the GNU General Public License. >> This exception does not however invalidate any other reasons why >> the executable file might be covered by the GNU General Public = License. */ >>=20 >> So in contexts were clang/llvm is used to exclusion . . . are >> any such files in use? (I happen to be using devel/powerpc64-gcc at >> the moment.) >>=20 >> For me this has no real implications: I do not distribute >> my experiments. But I was surprised by what I read. >>=20 >> Looking I find: >>=20 >> # grep -r "some of which are compiled with GCC" /usr/src/* | more >> /usr/src/contrib/gcc/config/i386/gthr-win32.c: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/config/ia64/crtend.asm: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/config/ia64/fde-glibc.c: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/config/ia64/crtbegin.asm: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/config/ia64/lib1funcs.asm: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/config/ia64/crtfastmath.c: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/config/ia64/unwind-ia64.c: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/config/mips/mips16.S: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/config/vxlib.c: some of which are compiled = with GCC, to produce an executable, >> /usr/src/contrib/gcc/libgcc2.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-posix95.h: some of which are compiled = with GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-posix.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-posix.c: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gbl-ctors.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-gnat.c: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-rtems.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-vxworks.h: some of which are compiled = with GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-dce.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-nks.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-tpf.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-aix.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-lynx.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-solaris.h: some of which are compiled = with GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr.h: some of which are compiled with GCC, = to produce an executable, >> /usr/src/contrib/gcc/gcov-io.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-gnat.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-single.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/gthr-win32.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/tsystem.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/typeclass.h: some of which are compiled with = GCC, to produce an executable, >> /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c: some of which are = compiled with GCC, to produce an executable, >> /usr/src/contrib/gcc/unwind-dw2-fde-darwin.c: some of which are = compiled with GCC, to produce an executable, >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sun Oct 14 02:55:10 2018 Return-Path: Delivered-To: freebsd-toolchain@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 8062310C07AD for ; Sun, 14 Oct 2018 02:55:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 052DF74B9A for ; Sun, 14 Oct 2018 02:55:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: MeECsXEVM1mPom3Zl28sGCPJhj3b9oS4Hhh6Tt2SYTDs41ePYngoowVSgkXKglV MAHHQ1mNxRjbortaqflht83NGJ6GlIlsSaUSlqRvT5B7FiWOhrb81.5u09Cwj5D5ASO_IOJ8xiMP 0sc3zwhRI_56KlzrscH.WGwB4pCfvQlD8jONXS12RVRiPKE15uakF9k4xLeV8uoX2YD6ZYBMpSho ZZPFiHI0nCaM36p4v84EeUsz2plgtl085s5NyH07YGcEn7bK5tFUWPvzk9lIE46L9vAEaivz86bK tosiL9Sr9NPW.azPE.TDLycLkub4TJeeh35sHwVjqwalCl_pFSE3wR8hPOcLRa3yL9xn3K2alS_x aPLR.shktmwKeXb3KjJSWKuv6zcqCzROPC_M797drzaGXYLdxpDATgnVLrHGWOZC2qdKX5mtmVGz HN1VDjBn10DSyUk3Nq9JQic1MDs27jWGNzMzJDYoBjLIsuFKI9lQUdVfjPLq2ycBV.Dcp1UlmUK3 Dsbh4WPvMG5HgSwAzZkd_av_CkibDVyxJzv7MMvJovad_WBMQsSaK87UaqraKLIJsDOY1eO.9GbL m_MDwqvFPE2pN9fln8Rk5PKTQ2gvtQwQNVTikGml9XgbGqfl2t0UvCcWXagOUQlkEXq5zeIHCVeI dHCCGp8_ref4T_SwGZS4gag5NReOnOl6EwPOSIRGfxEx8YY0h59wbG5TD4kTuQywGUKtm3HcQt5n aYBigrCHRsvZKoRAueMOE0qlR.4ylaIfZWjD8rTcjf.RyLmMYcBiWUr4JsjtEzkKzBfso.K1N5eo 3gms_xkbFQk380Q6PBhfTG_eio3YS_qOZtV.OZgc43BsQCY94kOlPmn6GQE8b_Pt5PYaf9YqwMc6 whQOzXiR.QN9HiExqh753qgq2QfIbr2dT6nebU53hFHTNsDkFwOuyuhHmsCER6KXNSVXRlhQVthW BFQtQkHcoqIiamC8Ry6MDvwFRyKXcTY9ho5kZghhbK41vYlujA2fpZdJXTX7tA7ej4qCMYhJBj5E igO0UDV2xk_tFPGKAF3dF3qzCa_MT9bRVf.onfwME5naUM7DhOo.BRxqzzUa2ugTDXsFzG4ABOgT twP7fcA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 Oct 2018 02:55:02 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp424.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID df806d173a48fc7c698ff08210daf5fc; Sun, 14 Oct 2018 02:54:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: GPL requirements vs. "some of which are compiled with GCC" terms in special exceptions? From: Mark Millard In-Reply-To: Date: Sat, 13 Oct 2018 19:54:58 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <5449BAA6-E022-4DE4-870A-8AE132A6F9FA@yahoo.com> <61B6C299-2F93-4678-8928-3CABDFED6623@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 02:55:10 -0000 On 2018-Oct-13, at 7:40 PM, Mark Millard wrote: > On 2018-Oct-13, at 10:15 AM, David Chisnall = wrote: >=20 >> This is a known problem with the GCC runtime libraries. GCC 4.3 and = later have a much better exemption (which talks about any eligible = compilation process, rather than being compiled with GCC), but those are = GPLv3 and so unacceptable for FreeBSD. >=20 > I see. Good to know. Hmm. As of head -r339076 the src.conf man page says: WITHOUT_LLVM_LIBUNWIND Set to use GCC's stack unwinder (instead of LLVM's = libunwind). This is a default setting on arm/arm, arm/armv6, arm/armv7, powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and sparc64/sparc64. I believe arm/armv7, arm/armv6, and arm/arm are using clang for such vintages: WITH_CLANG_BOOTSTRAP Set to build the Clang C/C++ compiler during the bootstrap = phase of the build. This is a default setting on amd64/amd64, arm/arm, = arm/armv6, arm/armv7, arm64/aarch64 and i386/i386. But may be the man page is just out of date for WITHOUT_LLVM_LIBUNWIND ? >> I don=E2=80=99t believe that we are using any of those files on = platforms where clang is the default system compiler. LLVM=E2=80=99s = libUnwind should be able to handle PowerPC on Linux, so it=E2=80=99s = worth checking if this is the case on FreeBSD. >=20 > Last I tried llvm's libunwind for powerpc64 was back in = 2016-Dec/2017-Jan. > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 . There = was also > the llvm submittal 31590. >=20 > I might try it again at some point. But clang and llvm have other = issues for > use for buildworld buildkernel as well as I understand. (But I'm doing = some > new experiments these days.) >=20 > I've no clue if llvm's libunwind is intended to be compliant with the > powerpc64 and powerpc ABIs that FreeBSD bases itself on for the = powerpc > family. >=20 >>> On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain = wrote: >>>=20 >>> While investigating powerpc64 C++ exception handling for >>> builds under devel/powerpc64-gcc I ran into the following >>> in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c : >>>=20 >>> /* As a special exception, if you link this library with other = files, >>> some of which are compiled with GCC, to produce an executable, >>> this library does not by itself cause the resulting executable >>> to be covered by the GNU General Public License. >>> This exception does not however invalidate any other reasons why >>> the executable file might be covered by the GNU General Public = License. */ >>>=20 >>> So in contexts were clang/llvm is used to exclusion . . . are >>> any such files in use? (I happen to be using devel/powerpc64-gcc at >>> the moment.) >>>=20 >>> For me this has no real implications: I do not distribute >>> my experiments. But I was surprised by what I read. >>>=20 >>> Looking I find: >>>=20 >>> # grep -r "some of which are compiled with GCC" /usr/src/* | more >>> /usr/src/contrib/gcc/config/i386/gthr-win32.c: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/config/ia64/crtend.asm: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/config/ia64/fde-glibc.c: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/config/ia64/crtbegin.asm: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/config/ia64/lib1funcs.asm: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/config/ia64/crtfastmath.c: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/config/ia64/unwind-ia64.c: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/config/mips/mips16.S: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/config/vxlib.c: some of which are compiled = with GCC, to produce an executable, >>> /usr/src/contrib/gcc/libgcc2.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-posix95.h: some of which are compiled = with GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-posix.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-posix.c: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gbl-ctors.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-gnat.c: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-rtems.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-vxworks.h: some of which are compiled = with GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-dce.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-nks.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-tpf.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-aix.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-lynx.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-solaris.h: some of which are compiled = with GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr.h: some of which are compiled with GCC, = to produce an executable, >>> /usr/src/contrib/gcc/gcov-io.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-gnat.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-single.h: some of which are compiled = with GCC, to produce an executable, >>> /usr/src/contrib/gcc/gthr-win32.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/tsystem.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/typeclass.h: some of which are compiled with = GCC, to produce an executable, >>> /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c: some of which are = compiled with GCC, to produce an executable, >>> /usr/src/contrib/gcc/unwind-dw2-fde-darwin.c: some of which are = compiled with GCC, to produce an executable, >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sun Oct 14 16:30:09 2018 Return-Path: Delivered-To: freebsd-toolchain@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 095A510D9E25 for ; Sun, 14 Oct 2018 16:30:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6E88FC8D for ; Sun, 14 Oct 2018 16:30:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 601EC10D9E22; Sun, 14 Oct 2018 16:30:08 +0000 (UTC) Delivered-To: toolchain@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 4F13B10D9E20 for ; Sun, 14 Oct 2018 16:30:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E36348FC84 for ; Sun, 14 Oct 2018 16:30:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 37C8F14AA7 for ; Sun, 14 Oct 2018 16:30:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9EGU7IR065240 for ; Sun, 14 Oct 2018 16:30:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9EGU7Iq065239 for toolchain@FreeBSD.org; Sun, 14 Oct 2018 16:30:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230412] graphics/GraphicsMagick: fails to build with libc++ 7 Date: Sun, 14 Oct 2018 16:30:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 16:30:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230412 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: sunpoet Date: Sun Oct 14 16:29:18 UTC 2018 New revision: 482063 URL: https://svnweb.freebsd.org/changeset/ports/482063 Log: Fix build with libc++ 7 PR: 230412 Reported by: jbeich Submitted by: dim Changes: head/graphics/GraphicsMagick/Makefile --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Oct 14 17:39:14 2018 Return-Path: Delivered-To: freebsd-toolchain@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 A59AD10DCBFF for ; Sun, 14 Oct 2018 17:39:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB1D94049 for ; Sun, 14 Oct 2018 17:39:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 01BD010DCBFC; Sun, 14 Oct 2018 17:39:14 +0000 (UTC) Delivered-To: toolchain@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 E438110DCBFB for ; Sun, 14 Oct 2018 17:39:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 815C894040 for ; Sun, 14 Oct 2018 17:39:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id CB4D91547B for ; Sun, 14 Oct 2018 17:39:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9EHdCC6034308 for ; Sun, 14 Oct 2018 17:39:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9EHdCof034307 for toolchain@FreeBSD.org; Sun, 14 Oct 2018 17:39:12 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230412] graphics/GraphicsMagick: fails to build with libc++ 7 Date: Sun, 14 Oct 2018 17:39:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sunpoet@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 17:39:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230412 Sunpoet Po-Chuan Hsieh changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #8 from Sunpoet Po-Chuan Hsieh --- Committed. Thanks! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Oct 15 16:16:43 2018 Return-Path: Delivered-To: freebsd-toolchain@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 08A7610B7DC1 for ; Mon, 15 Oct 2018 16:16:43 +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 B43F17A7B6 for ; Mon, 15 Oct 2018 16:16:42 +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 A1C9210B476; Mon, 15 Oct 2018 12:16:40 -0400 (EDT) Subject: Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build To: Mark Millard , FreeBSD Toolchain References: <925D3E9A-4EF0-4B49-83D4-C9574170EB66@yahoo.com> From: John Baldwin Message-ID: <4b7cb935-7643-da6c-261a-d69e9f155c78@FreeBSD.org> Date: Mon, 15 Oct 2018 09:16:55 -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: <925D3E9A-4EF0-4B49-83D4-C9574170EB66@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 15 Oct 2018 12:16:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 16:16:43 -0000 On 10/12/18 6:51 AM, Mark Millard wrote: > The following is from attempting to build devel/powerpc-gcc > via poudriere-devel on the powerpc64 system after having > bootstrapped via (in part) base/binutils and the .txz > produced on the host (amd64). > > Looks like having both: > > /usr/bin/powerpc64-unknown-freebsd12.0-* > and: > /usr/local/bin/powerpc64-unknown-freebsd12.0-* > > in a powerpc64 environment confuses "phase: build-depends" > in poudriere for the devel/powerpc64-gcc build: Ah, I could see that. I had kept the longer binary names with the full tuple since the original base/binutils had them, but I've considered stripping them as we only really need /usr/bin/as, etc. for the base system. I hadn't gotten to the point of trying to build any ports with base/* as I'm still trying to just do a buildworld (and running poudriere in a qemu image of mips64 would be very unpleasant). I think probably base/binutils just needs to drop the names with a full tuple if possible. -- John Baldwin                                                                              From owner-freebsd-toolchain@freebsd.org Mon Oct 15 16:20:07 2018 Return-Path: Delivered-To: freebsd-toolchain@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 273CD10C1015 for ; Mon, 15 Oct 2018 16:20:07 +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 D1F1E7A94C for ; Mon, 15 Oct 2018 16:20:06 +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 1898710AFCD; Mon, 15 Oct 2018 12:20:06 -0400 (EDT) Subject: Re: "base/binutils should not be pulling in any other ports at all"? (That confuses me.) To: Mark Millard References: <4C338B84-1179-4569-A964-CA18A22AF1D7@yahoo.com> <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> Cc: FreeBSD Toolchain From: John Baldwin Message-ID: Date: Mon, 15 Oct 2018 09:20:03 -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: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 15 Oct 2018 12:20:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 16:20:07 -0000 On 10/12/18 5:48 PM, Mark Millard wrote: > On 2018-Oct-10, at 3:13 PM, John Baldwin wrote: > >> On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote: >>> [Actually devel/gettext-tools is a build time dependency: it should not be using >>> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=. . . >>> It looks like the /usr/local/lib references are correct but the wrong linker was >>> being used. About 5 other ports have a similar status for making base/binutils >>> as a cross build.] >> >> base/binutils should not be pulling in any other ports at all. > > That last quote confuses me still. May be it means > it is all to be manually managed instead of automatic? No, it means it doesn't work as you ran into. :) > (The actual build using things link devel/bison on > the host if base/binutils is to build at all.) > > All versions of binutils have direct build dependencies on: > > math/gmp > math/mpfr > devel/bison > devel/gmake > > as far as I know. Some of those in turn have more > build dependencies. Some of all that have Runtime > dependencies and/or library dependencies as well. > (Host context of usage.) For the purposes of the instructions we only need to provide the top-level "leaf" packages as a list of things to install before trying to build. -- John Baldwin                                                                              From owner-freebsd-toolchain@freebsd.org Mon Oct 15 18:06:38 2018 Return-Path: Delivered-To: freebsd-toolchain@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 C860710C3991 for ; Mon, 15 Oct 2018 18:06:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69A4F7E5D8 for ; Mon, 15 Oct 2018 18:06:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe30.google.com with SMTP id a202so16797713vsd.5 for ; Mon, 15 Oct 2018 11:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HSXJUhD9VG4GyOQqAtvFL2as5M9pEVRov8QYgPuhRWU=; b=Q8kRohOvclGm0l3hA4eqh1NJH5wv4IMO8QmjOZXlvhqflFDFk0tvX9ozGOOdzRxBQX 1EPIwL9GzwPGNOlw8wuyAh1+M3ya9yFwjrRC+cbT2JtGxCboFqURu0V8nioBZYY4NOip eKDKuSOZEFKbnfxwGSM4u1Q7N9srYcVx2Za6zTH6vRpo2AkI7JgEhpAccK19wW0aF0lr Yc+cYINiZTFyhoJw+brXXa3aXTjI5NmZ9U1Xkf7kjNw9O7esH35NDgSpox3CIE0EUk4U NoxN3TM/eXmAiascYhEUafEkFDLP+kQ/eDNh82Los36s+GoMA37OS2mY8SvfO9S6KQMF apRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HSXJUhD9VG4GyOQqAtvFL2as5M9pEVRov8QYgPuhRWU=; b=Js6fryEIOpU+zGxtGS/LYAO78PrNEqUx+PFWLzqz38O21O4fsfA7XlDtA+XJWyYtCA kn6XciuQvhLmxLwXrNUcntAlaFu64vswqVcJnqIEh/Hubeam7/mNlHXbi5APfzYNt1yl V2FAUMATRUiYp3fow1EY4HGBLfzx8iFuhk4Zjcf/Z4Hn2yBTrucgHbuoHnsEWOCsnqw0 0+lQcmVCf5AYtsg25xV1G/3QPLW2x0SqgEDRUJJWoD8XuhogHpPTFLPCc72I+WYgsuDN tWR1TCjJh19auu1AqozqnNZO8AfAz3mi8ZUdyMU3pmmTMhUIn1mcZRHIarHvIwsyBdCA j3kQ== X-Gm-Message-State: ABuFfojAxDlFpNLydPZorHziaYR1CzHVwoX7L9J3dC9HBrYwjy0kEIEG qaCfm6X2o5z077l9sXA9ZHRPcMNiTMSPUI/NqnjoJg== X-Google-Smtp-Source: ACcGV62DWf/OZUDym6sOG388Aw6nMQUdklWrgCtbx3PQNB9JXVblHHhgiLRhhvUn5DNxuCgYj01mZHUf34eMUPX1Kz0= X-Received: by 2002:a67:e86:: with SMTP id 128mr6989325vso.201.1539626797429; Mon, 15 Oct 2018 11:06:37 -0700 (PDT) MIME-Version: 1.0 References: <925D3E9A-4EF0-4B49-83D4-C9574170EB66@yahoo.com> <4b7cb935-7643-da6c-261a-d69e9f155c78@FreeBSD.org> In-Reply-To: <4b7cb935-7643-da6c-261a-d69e9f155c78@FreeBSD.org> From: Warner Losh Date: Mon, 15 Oct 2018 12:06:25 -0600 Message-ID: Subject: Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build To: John Baldwin Cc: Mark Millard , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 18:06:39 -0000 On Mon, Oct 15, 2018, 10:20 AM John Baldwin wrote: > On 10/12/18 6:51 AM, Mark Millard wrote: > > The following is from attempting to build devel/powerpc-gcc > > via poudriere-devel on the powerpc64 system after having > > bootstrapped via (in part) base/binutils and the .txz > > produced on the host (amd64). > > > > Looks like having both: > > > > /usr/bin/powerpc64-unknown-freebsd12.0-* > > and: > > /usr/local/bin/powerpc64-unknown-freebsd12.0-* > > > > in a powerpc64 environment confuses "phase: build-depends" > > in poudriere for the devel/powerpc64-gcc build: > > Ah, I could see that. I had kept the longer binary names with the full > tuple > since the original base/binutils had them, but I've considered stripping > them > as we only really need /usr/bin/as, etc. for the base system. I hadn't > gotten > to the point of trying to build any ports with base/* as I'm still trying > to > just do a buildworld (and running poudriere in a qemu image of mips64 would > be very unpleasant). I think probably base/binutils just needs to drop the > names with a full tuple if possible. > Having symlinks to the long names plays nicer with autoconf, of at least has in the past. Our build system doesn't care, though... Warner -- > John Baldwin > > > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to " > freebsd-toolchain-unsubscribe@freebsd.org" > From owner-freebsd-toolchain@freebsd.org Mon Oct 15 18:25:56 2018 Return-Path: Delivered-To: freebsd-toolchain@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 1550410C41A3 for ; Mon, 15 Oct 2018 18:25:56 +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 B45137F59E for ; Mon, 15 Oct 2018 18:25:55 +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 2780E10B429; Mon, 15 Oct 2018 14:25:53 -0400 (EDT) Subject: Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build To: Warner Losh References: <925D3E9A-4EF0-4B49-83D4-C9574170EB66@yahoo.com> <4b7cb935-7643-da6c-261a-d69e9f155c78@FreeBSD.org> Cc: Mark Millard , "freebsd-toolchain@FreeBSD.org" From: John Baldwin Message-ID: <27396a4d-7fe9-2540-dfd2-28ae75109e01@FreeBSD.org> Date: Mon, 15 Oct 2018 11:25:51 -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: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 15 Oct 2018 14:25:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 18:25:56 -0000 On 10/15/18 11:06 AM, Warner Losh wrote: > > > On Mon, Oct 15, 2018, 10:20 AM John Baldwin > wrote: > > On 10/12/18 6:51 AM, Mark Millard wrote: > > The following is from attempting to build devel/powerpc-gcc > > via poudriere-devel on the powerpc64 system after having > > bootstrapped via (in part) base/binutils and the .txz > > produced on the host (amd64). > > > > Looks like having both: > > > > /usr/bin/powerpc64-unknown-freebsd12.0-* > > and: > > /usr/local/bin/powerpc64-unknown-freebsd12.0-* > > > > in a powerpc64 environment confuses "phase: build-depends" > > in poudriere for the devel/powerpc64-gcc build: > > Ah, I could see that.  I had kept the longer binary names with the full tuple > since the original base/binutils had them, but I've considered stripping them > as we only really need /usr/bin/as, etc. for the base system.  I hadn't gotten > to the point of trying to build any ports with base/* as I'm still trying to > just do a buildworld (and running poudriere in a qemu image of mips64 would > be very unpleasant).  I think probably base/binutils just needs to drop the > names with a full tuple if possible. > > > Having symlinks to the long names plays nicer with autoconf, of at least has in the past. Our build system doesn't care, though... I think it only plays nicer for the port. We've never had /usr/bin/x86_64-freebsd-ld linked to /usr/bin/ld in base, and base/binutils' role is to provide /usr/bin/as, /usr/bin/ld, etc. -- John Baldwin                                                                              From owner-freebsd-toolchain@freebsd.org Mon Oct 15 18:55:13 2018 Return-Path: Delivered-To: freebsd-toolchain@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 56DBE10C4C50 for ; Mon, 15 Oct 2018 18:55:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E177D80647 for ; Mon, 15 Oct 2018 18:55:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe33.google.com with SMTP id y195so1134999vsc.7 for ; Mon, 15 Oct 2018 11:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xTOom5TqTE8+IE8Zkk7S6mhfX1OhoPD2Q6692oPgsdk=; b=f4ImzreOu5XllmI8avhb6jsoFGzbGy51bY/FAin7YLh1m76M6kfI3mk2tzs4RlPCwR 4nbISC0/SB4iXUKykoBafneB4BU9oMEewo31rKlV+FxML83Es2UdzwKy7uMd252geOzy Sd6gPmiXivIXILFqP7X6mPkgVijDPsdpTmEtIJgCMeW343WUrmDmJJnAJc2XJoKWrks+ KgunYYoZ07Yq5ynWmM2engW7Vx0mBqI+9f4bxWMgF+F1i/X45aU22nKdIxLItBCCgtUu oEm+2QgHACU14XgvpYu+qirUXQ9H4Rcl2ZNE+D5t7ns8oAyaz9QrV+c+Vf25BoscF6OU KLYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xTOom5TqTE8+IE8Zkk7S6mhfX1OhoPD2Q6692oPgsdk=; b=OENMSWgoK4XURJcNDCq+WnkGfTP17h62bZbnBN0AMfzmoozzJrMz4kToHememoom9O OzD6Dc4vquBEhKN3tQH/9A9RsFzmZdssZ9/PvxKt/5CQmXMotxq+DWQU0JRbHDv4GZsp xKribCoZcaHKQDAPcW4wd8LawK1XF0QsBmZXNTxOPE4tJIYOa/CyNnniUifu3wx1Pi8B nEj2QGqMqPn98FqJvM9XF9UOrKO2WxrN+c5vNfMLKHR53P+KZX0jOzHyqqHmkX4QUt5O B7I6rrUJlGZ13mTflZ4jAhJjXV036zKejFe/U8AWej74ydIVpg/euNeNoLmksf4an9uP 9reA== X-Gm-Message-State: ABuFfohR63gYAJbfM8EPcNMOkWVC7Rs9z2WtO1M3aajKTVN0mY6uRjSe W+jzzKYXIlun0M+qpe3yq8jlL/NpQOB7f2sYAbfYjA== X-Google-Smtp-Source: ACcGV62v0wpiX4IeHhvp89dgeCS+F+jk6Ktbdahha9lsnw1oU1qUKRQaW3etU0HnWK8ixEaaXFy3Cro0MH6nP7THZLM= X-Received: by 2002:a67:2704:: with SMTP id n4mr7471568vsn.209.1539629711984; Mon, 15 Oct 2018 11:55:11 -0700 (PDT) MIME-Version: 1.0 References: <925D3E9A-4EF0-4B49-83D4-C9574170EB66@yahoo.com> <4b7cb935-7643-da6c-261a-d69e9f155c78@FreeBSD.org> <27396a4d-7fe9-2540-dfd2-28ae75109e01@FreeBSD.org> In-Reply-To: <27396a4d-7fe9-2540-dfd2-28ae75109e01@FreeBSD.org> From: Warner Losh Date: Mon, 15 Oct 2018 12:55:00 -0600 Message-ID: Subject: Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build To: John Baldwin Cc: Mark Millard , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 18:55:13 -0000 On Mon, Oct 15, 2018 at 12:25 PM John Baldwin wrote: > On 10/15/18 11:06 AM, Warner Losh wrote: > > > > > > On Mon, Oct 15, 2018, 10:20 AM John Baldwin jhb@freebsd.org>> wrote: > > > > On 10/12/18 6:51 AM, Mark Millard wrote: > > > The following is from attempting to build devel/powerpc-gcc > > > via poudriere-devel on the powerpc64 system after having > > > bootstrapped via (in part) base/binutils and the .txz > > > produced on the host (amd64). > > > > > > Looks like having both: > > > > > > /usr/bin/powerpc64-unknown-freebsd12.0-* > > > and: > > > /usr/local/bin/powerpc64-unknown-freebsd12.0-* > > > > > > in a powerpc64 environment confuses "phase: build-depends" > > > in poudriere for the devel/powerpc64-gcc build: > > > > Ah, I could see that. I had kept the longer binary names with the > full tuple > > since the original base/binutils had them, but I've considered > stripping them > > as we only really need /usr/bin/as, etc. for the base system. I > hadn't gotten > > to the point of trying to build any ports with base/* as I'm still > trying to > > just do a buildworld (and running poudriere in a qemu image of > mips64 would > > be very unpleasant). I think probably base/binutils just needs to > drop the > > names with a full tuple if possible. > > > > > > Having symlinks to the long names plays nicer with autoconf, of at least > has in the past. Our build system doesn't care, though... > > I think it only plays nicer for the port. We've never had > /usr/bin/x86_64-freebsd-ld > linked to /usr/bin/ld in base, and base/binutils' role is to provide > /usr/bin/as, > /usr/bin/ld, etc. > The tools built by xdev did, though not that specific link... I do agree that if we do this, it's only of marginal benefit. Warner From owner-freebsd-toolchain@freebsd.org Mon Oct 15 20:33:10 2018 Return-Path: Delivered-To: freebsd-toolchain@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 C3E7410C8797 for ; Mon, 15 Oct 2018 20:33:10 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (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 6F61184211 for ; Mon, 15 Oct 2018 20:33:10 +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 C670C10AFCD; Mon, 15 Oct 2018 16:33:07 -0400 (EDT) Subject: Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build To: Warner Losh References: <925D3E9A-4EF0-4B49-83D4-C9574170EB66@yahoo.com> <4b7cb935-7643-da6c-261a-d69e9f155c78@FreeBSD.org> <27396a4d-7fe9-2540-dfd2-28ae75109e01@FreeBSD.org> Cc: Mark Millard , "freebsd-toolchain@FreeBSD.org" From: John Baldwin Message-ID: Date: Mon, 15 Oct 2018 13:33:05 -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: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 15 Oct 2018 16:33:09 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 20:33:11 -0000 On 10/15/18 11:55 AM, Warner Losh wrote: > > > On Mon, Oct 15, 2018 at 12:25 PM John Baldwin > wrote: > > On 10/15/18 11:06 AM, Warner Losh wrote: > > > > > > On Mon, Oct 15, 2018, 10:20 AM John Baldwin >> wrote: > > > >     On 10/12/18 6:51 AM, Mark Millard wrote: > >     > The following is from attempting to build devel/powerpc-gcc > >     > via poudriere-devel on the powerpc64 system after having > >     > bootstrapped via (in part) base/binutils and the .txz > >     > produced on the host (amd64). > >     > > >     > Looks like having both: > >     > > >     > /usr/bin/powerpc64-unknown-freebsd12.0-* > >     > and: > >     > /usr/local/bin/powerpc64-unknown-freebsd12.0-* > >     > > >     > in a powerpc64 environment confuses "phase: build-depends" > >     > in poudriere for the devel/powerpc64-gcc build: > > > >     Ah, I could see that.  I had kept the longer binary names with the full tuple > >     since the original base/binutils had them, but I've considered stripping them > >     as we only really need /usr/bin/as, etc. for the base system.  I hadn't gotten > >     to the point of trying to build any ports with base/* as I'm still trying to > >     just do a buildworld (and running poudriere in a qemu image of mips64 would > >     be very unpleasant).  I think probably base/binutils just needs to drop the > >     names with a full tuple if possible. > > > > > > Having symlinks to the long names plays nicer with autoconf, of at least has in the past. Our build system doesn't care, though... > > I think it only plays nicer for the port.  We've never had /usr/bin/x86_64-freebsd-ld > linked to /usr/bin/ld in base, and base/binutils' role is to provide /usr/bin/as, > /usr/bin/ld, etc. > > > The tools built by xdev did, though not that specific link... I do agree that if we do this, it's only of marginal benefit. The xdev tools are probably more inline with the devel/-binutils and devel/-gcc ports which do install those links to be cross-build friendly. -- John Baldwin                                                                              From owner-freebsd-toolchain@freebsd.org Tue Oct 16 04:00:25 2018 Return-Path: Delivered-To: freebsd-toolchain@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 62C9610DFE77 for ; Tue, 16 Oct 2018 04:00:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 B91EF78E48 for ; Tue, 16 Oct 2018 04:00:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: z17AQoIVM1mbFSZ8AMx5keokcT1PbUjyxr1ezsLrKpbUDw5qAmuAM.VMo5Gik4t N4sE2VL7jB8Ygf0FccRtQ1TUoLmCWb_5hIVIfvJPbxR16N7VSVKW03uZ9QHA1.kz7nQE8wGVI_GP JY__t3tiCQSCIXa7WdwG5.RJxL8QgO.fR4WJ2QdrT4sokem.XdoMSVpu_UUBCUJ1hGgMBWOkyWsU eTRS9VvmxrEpYqYSOpkfe11kL_ILSVqrSVT2PmHYMGt7TT3aya0ksou.7jFUXl.Hc2ZO1sGYjms6 Wf56SBolvP0hXq34x0jKKu43HjWtibzwXjjuGr28IXEvxt.anLH1_0CDbzLUZVYWhXcO9RuqKAXR bMCJhTBRh1ru2iSiZPGWzkM.MWcdnjOF.VcPr4y.qAQNFdqDiG6LeppiIMta6wueo1SdAufDW8PV .dkSXVwdCc_lVQTeXRGyIY21V1J_KmyiuigFMZ6mdWmrP99dpsFXp52BylCfibqIdW.VQ55AcKQv CXBkHd9fXPbcwP.njaV7SZywy2UqrxB9AUWjJppbVVHO0BGvB9yK.pHZvsD8ZG1w8nhc7roWL0WF ArMFytAZut2mWOHTcNZ6jqKXcDnE41fh.If0YtpslBt0HFqfyv.vnIlsZOuM.WbRjGO0hzziRyIq 8VTwaDICKgwR8v4Imp4nEyQxYvFHd6o12SAT4nLpCrH.6sV73sPHYo6nQrTDX8_F_.9xDn.ojwk8 uKufXRQexAnhyQMv7f_DOtRDrF3kwjzX1Aoaq7vBU9XXcKMnX4BSYNfgr9vhJJqYtYiFtAUPUWMO ho3NherbyWZlGpbo6OkKmh0w_hvkod2BIdi5y5jJsQF2Qi990FmZP3rlWTEVFGJF4zw.PF5LNVfv ROek40xAQgUI3LV7ka7iEl48dTcPvxarkbzSma.FtL3tDP2DenTktDUUHdJHMjvwtkse6_iPFqJa 1D2HQxyURmkF6CXsXMHgba0wgF7wEHQ_00FMYTJVgPRE_ein_dxqoBmCD4Hiedjoo6GdzPZ62ook skq.TEmJN93Mehsc0Q_1.zMLK9efPp8TUnm55OmqyJj4H_pQuiXRgvdSoOWi_oUZmVCNUefNRgzl NoJszC.0dXmfNYA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 Oct 2018 04:00:18 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp431.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dd93d55728f71f0de1169e4749adc2d5; Tue, 16 Oct 2018 04:00:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: powerpc64 headbuilt via devel/powerpc64-xtoolchain-gcc and C++ exceptions for user code built by system-clang or devel/powerpc64-gcc (as of head -r339076 and ports -r480180) From: Mark Millard In-Reply-To: <0539C16B-1603-4639-914A-0308578C7262@yahoo.com> Date: Mon, 15 Oct 2018 21:00:17 -0700 Cc: Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <3B69D483-AEBA-47CA-B140-7445089EB064@yahoo.com> References: <0539C16B-1603-4639-914A-0308578C7262@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Mailing List X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 04:00:25 -0000 [I've found the problem at the low level for my context of using WITH_LIBCPLUSPLUS=3D with the likes of devel/powerpc64-gcc but I do not have a solution for WITH_LIBCPLUSPLUS=3D so far. I give details of what I found.] On 2018-Oct-14, at 12:40 AM, Mark Millard wrote: > On 2018-Oct-12, at 1:59 PM, Mark Millard wrote: >=20 >> I built a powerpc64 head -r339076 via devel/powerpc64-gcc >> and the like that built clang as cc as well (and >> WITHOUT_LIB32). This included use of base/binutils to >> the the powerpc64 set up. The system and kernel are >> non-debug builds (but with symbols). [system-clang is not >> used for buildworld buildkernel because of known >> issues (last I tried).] >>=20 >> booting, buildworld, buildkernel, poudriere building >> what totaled to be somewhat under 400 ports all seem >> to work. But . . . >>=20 >> It been a long time since I've done something analogous >> and a significant item in the result is different than in >> the past once I started testing the throwing of C++ >> exceptions in code produced by system-clang or by >> devel/powerpc64-gcc : >>=20 >> Such code ends up stuck using around 100% of a CPU. >> An example is the program: >>=20 >> # more exception_test.cpp >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >> For system-clang it ended up with: >>=20 >> # ldd a.out >> a.out: >> libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) >> libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) >> libm.so.5 =3D> /lib/libm.so.5 (0x8101ab000) >> libc.so.7 =3D> /lib/libc.so.7 (0x8101eb000) >> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810554000) >>=20 >> That program goes into an possibly unbounded execution. >> (Historically when this program had problems it would >> stop and produce a core file.) >>=20 >> When compiled by devel/powerpc64-gcc the a.out that results >> does the same thing. ( = /usr/local/bin/powerpc64-unknown-freebsd12.0-c++=20 >> as the compiler path ) So this is not really clang specific >> in any way. This ended up with: >>=20 >> # ldd a.out >> a.out: >> libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) >> libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) >> libm.so.5 =3D> /lib/libm.so.5 (0x8101ab000) >> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x8101eb000) >> libc.so.7 =3D> /lib/libc.so.7 (0x810211000) >>=20 >> (That should not have involved clang or llvm at all.) >>=20 >> But compiled by lang/gcc8's g++8 the a.out that results works >> fine. This ends up with: >>=20 >> # ldd a.out >> a.out: >> libstdc++.so.6 =3D> /usr/local/lib/gcc8/libstdc++.so.6 = (0x81006e000) >> libm.so.5 =3D> /lib/libm.so.5 (0x8102c7000) >> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810307000) >> libc.so.7 =3D> /lib/libc.so.7 (0x81032d000) >>=20 >> It is not clear if using base/gcc as system cc >> would do any better than using system-clang does >> or than devel/powerpc64-gcc does: it is sort of >> a variant of devel/powerpc64-gcc . >>=20 >> It will probably be some time before I figure out >> much about what is going on. >>=20 >> Two things common to the problem cases are: >>=20 >> libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) >> libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) >>=20 >> lang/gcc8 avoids those being involved. >>=20 >>=20 >> Notes: >>=20 >> . . . >>=20 >> WITHOUT_LIB32=3D is because, for every post-gcc 4.2.1 >> that I've tried, the lib32 produced misuses R30 in >> crtbeginS code (vs. the ABI for FreeBSD) and 32-bit >> code just produces core files from the bad so-called >> address dereference that results. >>=20 >> I'd rather have throwing C++ exceptions working and >> lack of lib32 than have lib32 but not have throwing >> C++ exceptions working. But at the moment how to have >> such is not obvious when fairly modern compilers >> and toolchains are involved.=20 >=20 > Here is what I've found so far. >=20 > The code is looping in the following routine. > (I've inserted 2 NOTE: lines for what the > sustained looping is like.) >=20 . . . (the routine was _Unwind_RaiseException) . . . So far I've found that the following in _Unwind_RaiseException stays invariant once initialized --despite the uw_frame_state_for and uw_update_context calls in _Unwind_RaiseException 's loop that normally update fs: (gdb) print fs $15 =3D {regs =3D {reg =3D {{loc =3D {reg =3D 0, offset =3D 0, exp =3D = 0x0}, how =3D REG_UNSAVED} , {loc =3D {reg =3D = 18446744073709551608, offset =3D -8,=20 exp =3D 0xfffffffffffffff8 }, how =3D REG_SAVED_OFFSET}, {loc =3D = {reg =3D 0, offset =3D 0, exp =3D 0x0}, how =3D REG_UNSAVED} , { loc =3D {reg =3D 16, offset =3D 16, exp =3D 0x10 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D = 0, offset =3D 0, exp =3D 0x0}, how =3D REG_UNSAVED} },=20= prev =3D 0x0}, cfa_offset =3D 0, cfa_reg =3D 1, cfa_exp =3D 0x0, = cfa_how =3D CFA_REG_OFFSET, pc =3D 0x8101999f8, personality =3D 0, = data_align =3D -8, code_align =3D 4, retaddr_column =3D 65,=20 fde_encoding =3D 27 '\033', lsda_encoding =3D 255 '?', saw_z =3D 1 = '\001', signal_frame =3D 0 '\0', eh_ptr =3D 0x0} It turns out that pc value 0x8101999f8 is a little after the libcxxrt.so call to _Unwind_RaiseException that is in throw_exception. But _Unwind_RaiseException returning would be a failure and would end up in a non-returning, error-reporting code path. In other words: this is not an appropriate context for following the return path to unwind out of _Unwind_RaiseException and its internal caller (throw_exception). It got to that address from lr containing the address of the instruction after the one that does bl to the _Unwind_RaiseException routine. Overall it needs to unwind past this in the normal case but is stuck handling the error/no-return case as "the" case. Supporting details follow. What lead up to 0x8101999f8 for initialization was the lr value related to calling _Unwind_RaiseException (see the address in lr below, also copied to r5): . . . (gdb) c Continuing. Breakpoint 9, 1: x/i $pc 0x8101f35d8 <_Unwind_RaiseException+216>: bl = 0x8101f2bc0 Current language: auto; currently minimal where the register values being supplied are (see r5 and lr): (gdb) info reg r0 0x8101999f0 34629851632 r1 0x3fffffffffffc320 4611686018427372320 r2 0x810217900 34630367488 r3 0x3fffffffffffd280 4611686018427376256 r4 0x3fffffffffffd930 4611686018427377968 r5 0x8101999f0 34629851632 r6 0xa0 160 r7 0x0 0 r8 0x1 1 r9 0x8101aac10 34629921808 r10 0x1 1 r11 0x28 40 r12 0x28000282 671089282 r13 0x81005d020 34628554784 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x0 0 r19 0x0 0 r20 0x0 0 r21 0x0 0 r22 0x0 0 r23 0x0 0 r24 0x0 0 r25 0x0 0 r26 0x0 0 r27 0x3fffffffffffd280 4611686018427376256 r28 0x810041060 34628440160 r29 0x3fffffffffffc390 4611686018427372432 r30 0x3fffffffffffcd10 4611686018427374864 r31 0x810041008 34628440072 pc 0x8101f35d8 34630219224 ps 0x0 0 cr 0x0 0 lr 0x8101999f0 34629851632 ctr 0x8101f3500 34630219008 xer 0x0 0 fpscr 0xfff80000 -524288 vscr 0x0 0 vrsave 0x0 0 The pc listed in print fs (0x8101999f8) is in the following from libcxxrt, as is the value in r5 and lr (0x8101999f0): (some blank lines inserted to help identify the area and some related material) (gdb) disass throw_exception Dump of assembler code for function throw_exception: 0x0000000810199960 : mflr r0 0x0000000810199964 : std r31,-8(r1) 0x0000000810199968 : mr r31,r3 0x000000081019996c : std r0,16(r1) 0x0000000810199970 : stdu r1,-128(r1) 0x0000000810199974 : bl 0x810197ab0 = 0x0000000810199978 : ld r10,8(r3) 0x000000081019997c : mr r9,r3 0x0000000810199980 : cmpdi cr7,r10,0 0x0000000810199984 : std r10,24(r31) 0x0000000810199988 : beq- cr7,0x810199a10 = 0x000000081019998c : ld r10,0(r9) 0x0000000810199990 : cmpdi cr7,r10,0 0x0000000810199994 : std r10,32(r31) 0x0000000810199998 : beq- cr7,0x8101999d0 = 0x000000081019999c : lwz r10,48(r9) 0x00000008101999a0 : addi r3,r31,88 0x00000008101999a4 : addi r10,r10,1 0x00000008101999a8 : stw r10,48(r9) 0x00000008101999ac : bl 0x81018e500 = <00000018.plt_call._Unwind_RaiseException@@GCC_3.0> 0x00000008101999b0 : ld r2,40(r1) 0x00000008101999b4 : addi r1,r1,128 0x00000008101999b8 : mr r4,r31 0x00000008101999bc : ld r0,16(r1) 0x00000008101999c0 : ld r31,-8(r1) 0x00000008101999c4 : mtlr r0 0x00000008101999c8 : b 0x8101996b0 = 0x00000008101999cc : nop 0x00000008101999d0 : nop 0x00000008101999d4 : addi r3,r31,88 0x00000008101999d8 : ld r10,-30008(r2) 0x00000008101999dc : std r10,32(r31) 0x00000008101999e0 : lwz r10,48(r9) 0x00000008101999e4 : addi r10,r10,1 0x00000008101999e8 : stw r10,48(r9) 0x00000008101999ec : bl 0x81018e500 = <00000018.plt_call._Unwind_RaiseException@@GCC_3.0> 0x00000008101999f0 : ld r2,40(r1) 0x00000008101999f4 : addi r1,r1,128 0x00000008101999f8 : mr r4,r31 0x00000008101999fc : ld r0,16(r1) 0x0000000810199a00 : ld r31,-8(r1) 0x0000000810199a04 : mtlr r0 0x0000000810199a08 : b 0x8101996b0 = 0x0000000810199a0c : nop 0x0000000810199a10 : nop 0x0000000810199a14 : ld r10,-30000(r2) 0x0000000810199a18 : std r10,24(r31) 0x0000000810199a1c : b 0x81019998c = 0x0000000810199a20 : .long 0x0 0x0000000810199a24 : .long 0x90001 0x0000000810199a28 : lwz r0,0(r1) End of assembler dump. For: 0x00000008101999f8 (above) objdump shows: 00000000000159f8 (below): 0000000000015960 <.__cxa_end_catch+0x460> mflr r0 0000000000015964 <.__cxa_end_catch+0x464> std r31,-8(r1) 0000000000015968 <.__cxa_end_catch+0x468> mr r31,r3 000000000001596c <.__cxa_end_catch+0x46c> std r0,16(r1) 0000000000015970 <.__cxa_end_catch+0x470> stdu r1,-128(r1) 0000000000015974 <.__cxa_end_catch+0x474> bl 0000000000013ab0 = <._ZdaPv+0x590> 0000000000015978 <.__cxa_end_catch+0x478> ld r10,8(r3) 000000000001597c <.__cxa_end_catch+0x47c> mr r9,r3 0000000000015980 <.__cxa_end_catch+0x480> cmpdi cr7,r10,0 0000000000015984 <.__cxa_end_catch+0x484> std r10,24(r31) 0000000000015988 <.__cxa_end_catch+0x488> beq cr7,0000000000015a10 = <.__cxa_end_catch+0x510> 000000000001598c <.__cxa_end_catch+0x48c> ld r10,0(r9) 0000000000015990 <.__cxa_end_catch+0x490> cmpdi cr7,r10,0 0000000000015994 <.__cxa_end_catch+0x494> std r10,32(r31) 0000000000015998 <.__cxa_end_catch+0x498> beq cr7,00000000000159d0 = <.__cxa_end_catch+0x4d0> 000000000001599c <.__cxa_end_catch+0x49c> lwz r10,48(r9) 00000000000159a0 <.__cxa_end_catch+0x4a0> addi r3,r31,88 00000000000159a4 <.__cxa_end_catch+0x4a4> addi r10,r10,1 00000000000159a8 <.__cxa_end_catch+0x4a8> stw r10,48(r9) 00000000000159ac <.__cxa_end_catch+0x4ac> bl 000000000000a500 = 00000000000159b0 <.__cxa_end_catch+0x4b0> ld r2,40(r1) 00000000000159b4 <.__cxa_end_catch+0x4b4> addi r1,r1,128 00000000000159b8 <.__cxa_end_catch+0x4b8> mr r4,r31 00000000000159bc <.__cxa_end_catch+0x4bc> ld r0,16(r1) 00000000000159c0 <.__cxa_end_catch+0x4c0> ld r31,-8(r1) 00000000000159c4 <.__cxa_end_catch+0x4c4> mtlr r0 00000000000159c8 <.__cxa_end_catch+0x4c8> b 00000000000156b0 = <.__cxa_end_catch+0x1b0> 00000000000159cc <.__cxa_end_catch+0x4cc> nop 00000000000159d0 <.__cxa_end_catch+0x4d0> nop 00000000000159d4 <.__cxa_end_catch+0x4d4> addi r3,r31,88 00000000000159d8 <.__cxa_end_catch+0x4d8> ld r10,-30008(r2) 00000000000159dc <.__cxa_end_catch+0x4dc> std r10,32(r31) 00000000000159e0 <.__cxa_end_catch+0x4e0> lwz r10,48(r9) 00000000000159e4 <.__cxa_end_catch+0x4e4> addi r10,r10,1 00000000000159e8 <.__cxa_end_catch+0x4e8> stw r10,48(r9) 00000000000159ec <.__cxa_end_catch+0x4ec> bl 000000000000a500 = 00000000000159f0 <.__cxa_end_catch+0x4f0> ld r2,40(r1) 00000000000159f4 <.__cxa_end_catch+0x4f4> addi r1,r1,128 00000000000159f8 <.__cxa_end_catch+0x4f8> mr r4,r31 00000000000159fc <.__cxa_end_catch+0x4fc> ld r0,16(r1) 0000000000015a00 <.__cxa_end_catch+0x500> ld r31,-8(r1) 0000000000015a04 <.__cxa_end_catch+0x504> mtlr r0 0000000000015a08 <.__cxa_end_catch+0x508> b 00000000000156b0 = <.__cxa_end_catch+0x1b0> 0000000000015a0c <.__cxa_end_catch+0x50c> nop 0000000000015a10 <.__cxa_end_catch+0x510> nop 0000000000015a14 <.__cxa_end_catch+0x514> ld r10,-30000(r2) 0000000000015a18 <.__cxa_end_catch+0x518> std r10,24(r31) 0000000000015a1c <.__cxa_end_catch+0x51c> b 000000000001598c = <.__cxa_end_catch+0x48c> 0000000000015a20 <.__cxa_end_catch+0x520> .long 0x0 0000000000015a24 <.__cxa_end_catch+0x524> .long 0x90001 0000000000015a28 <.__cxa_end_catch+0x528> lwz r0,0(r1) And dwarfdump shows starting at 0x00015960 as: < 117><0x00015960:0x00015a2c><> 0x00015960: =20 0x00015968: =20 0x00015974: =20 0x000159b8: =20 0x000159c8: =20 0x000159d0: =20 0x000159f8: =20 0x00015a08: =20 0x00015a10: =20 fde section offset 4120 0x00001018 cie offset for fde: 4124 0x0000101c 0 DW_CFA_advance_loc 8 (2 * 4) 1 DW_CFA_register r65 =3D r0 4 DW_CFA_offset r31 -8 (1 * -8) 6 DW_CFA_advance_loc 12 (3 * 4) 7 DW_CFA_def_cfa_offset 128 10 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 13 DW_CFA_advance_loc 68 (17 * 4) 14 DW_CFA_remember_state 15 DW_CFA_def_cfa_offset 0 17 DW_CFA_advance_loc 16 (4 * 4) 18 DW_CFA_restore_extended r65 20 DW_CFA_restore r31 21 DW_CFA_advance_loc 8 (2 * 4) 22 DW_CFA_restore_state 23 DW_CFA_advance_loc 40 (10 * 4) 24 DW_CFA_remember_state 25 DW_CFA_def_cfa_offset 0 27 DW_CFA_advance_loc 16 (4 * 4) 28 DW_CFA_restore_extended r65 30 DW_CFA_restore r31 31 DW_CFA_advance_loc 8 (2 * 4) 32 DW_CFA_restore_state 33 DW_CFA_nop 34 DW_CFA_nop /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc has something that /usr/src/contrib/libcxxrt/exception.cc does not have in its error handling code path: a use of __cxa_begin_catch=20 in __cxxabiv1::__cxa_throw : #ifdef _GLIBCXX_SJLJ_EXCEPTIONS _Unwind_SjLj_RaiseException (&header->unwindHeader); #else _Unwind_RaiseException (&header->unwindHeader); #endif // Some sort of unwinding error. Note that terminate is a handler. __cxa_begin_catch (&header->unwindHeader); std::terminate (); It looks to me like __cxa_begin_catch might do either of terminate or _Unwind_Resume and that the (conditional) _Unwind_Resume case is possibly needed here for the normal execution. There are also no other calls (bl's) before the terminate: more directly indicated to not return. I do not know if one or both of those points helped the code unwind correctly or not. But it seems suggestive. Other notes: I've demonstrated the problem on my prior head -r333594 environment that had been build via a 6.3 vintage of devel/powerpc64-gcc (but that was then updated to ports -r469844 and so had 6.4 of devel/powerpc64-gcc installed). Also: base/binutils was of a 2.30 vintage and base/gcc was of a 6.3 vintage. (system-clang was not cc, base/gcc provided system-cc.) Compiling to produce the a.out via: /usr/bin/powerpc64-unknown-freebsd12.0-g++ (and so via a 6.3 vintage g++) made no difference. It still had the problem. I have taken to having buildworld buildkernel use -gdwarf-2 so that /usr/libexec/gdb has access to the information in a format it is (mostly) designed for. (/usr/local/bin/gdb is broken by the thrown-C++-exception problem that I'm investigating: gdb internally throws exceptions in normal operation.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Tue Oct 16 06:53:12 2018 Return-Path: Delivered-To: freebsd-toolchain@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 2029210E4037 for ; Tue, 16 Oct 2018 06:53:12 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB9087DEE4; Tue, 16 Oct 2018 06:53:11 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from mandree.no-ip.org (p4FE523F4.dip0.t-ipconnect.de [79.229.35.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: mandree/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A30921FD32; Tue, 16 Oct 2018 06:53:11 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from ryzen.an3e.de (localhost [IPv6:::1]) by ryzen.an3e.de (Postfix) with ESMTP id 36CAF12028B; Tue, 16 Oct 2018 08:53:09 +0200 (CEST) To: freebsd-toolchain@freebsd.org, Baptiste Daroussin References: <156D3788-3987-40AF-BE9B-4DDC8FC53600@yahoo.com> From: Matthias Andree Openpgp: id=DC4A655BD993CD4871FA8210E412B156EFF3855A Subject: Re: xmlcharent-0.3_2 and iso8879-1986_3 package reinstalls: "pkg: POST-INSTALL script failed"? vs. @xmlcatmgr and Keywords/xmlcatmgr.ucl Message-ID: <457ddc44-3dbe-e0c3-4c4d-59d64af8af59@FreeBSD.org> Date: Tue, 16 Oct 2018 08:53:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <156D3788-3987-40AF-BE9B-4DDC8FC53600@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 06:53:12 -0000 Am 11.10.18 um 17:39 schrieb Mark Millard via freebsd-toolchain: > In updating a powerpc64 context after a poudriere-devel bulk run, I > got the following from pkg upgrade . . . > > Installed packages to be REINSTALLED: xmlcharent-0.3_2 (ABI changed: 'freebsd:12:powerpc:64' -> 'freebsd:12:*') > . . . > iso8879-1986_3 (ABI changed: 'freebsd:12:powerpc:64' -> 'freebsd:12:*') > . . . > > [127/181] Extracting iso8879-1986_3: 100% > xmlcatmgr: entry already exists for `/usr/local/share/sgml/iso8879/catalog' of type `CATALOG' > pkg: POST-INSTALL script failed > > . . . > > [138/181] Extracting xmlcharent-0.3_2: 100% > xmlcatmgr: entry already exists for `/usr/local/share/xml/xmlcharent/catalog' of type `CATALOG' > xmlcatmgr: entry already exists for `/usr/local/share/xml/xmlcharent/catalog.xml' of type `nextCatalog' > pkg: POST-INSTALL script failed > > The context is a personal head-based -r339076 buildworld > buildkernel (it was cross built) and ports being updated > based on -r480180 . > > Is there anything that I should do because of the messages? Mark, no need, it seems the failure is harmless on upgrades. It appears to be a bug in the @xmlchatmgr lines for pkg-plist files, and I have seen these xmlcatmgr complaints you are showing for ages on all ports that install SGML or XML catalogs when they are upgraded, if you manually deinstall (pkg delete -f) and reinstall these ports, they do not appear. I question the ports/Keywords/xmlcatmgr.ucl and wonder if what is currently labelled a post-deinstall action should become a pre-deinstall action - and unfortunately, I have not found documentation on this so cannot propose a patch. Possibly we also need a pre-/post-upgrade action pair to solve this. Baptiste, any insights? From owner-freebsd-toolchain@freebsd.org Tue Oct 16 16:15:13 2018 Return-Path: Delivered-To: freebsd-toolchain@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 968FC10D9198 for ; Tue, 16 Oct 2018 16:15:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.34]) (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 377EF73D2A for ; Tue, 16 Oct 2018 16:15:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 84LR00oVM1ns4S4PA3bdlEUO7uvqr38VuORfYuBtwbpl.Zb_BbKBfqafbzt2goe eKE4G2CdtKHdp_Vskw.0bS71OblvvxkVzueDUmfSEJXxN4d0TisfWCZaS.7fujSIms5DPiFqH42S xFyMLBCBdiMHIJPvPFPIpiBjAiSQXooAs4nNiatObk22evvxRdYgpRJ2e__Dc4F1FFwBt5qK9m1B v2vtxsXgOvX1XYLoIsM2aVKoDV0.bzKlu0UghLGDEmQq5PAMCZJ4Jb_g5_GUOQvawUMoZVXreFw. 0VzJ77B0tGir1DK2Ff0jqBl_X1ZtivMjdrk4o4JsaW._CzFH2DsZSdEAFxTgY.ii5rc7NNxVEpgU yur.pr4ypAzWNAZ0hAaEHCtNbE4CHCa6O0ClZWuOA_.ho4l0txwUdSoTsreX1yFz8pre3qCZYPtg po0f002Q9XKAwxmuZAwoC6gvp.1tzkRrpIMlYRZknTSWLJduMvBWbPGKtnvglh1jySR9IWnxplVl 3Ixw8PRiyErZGRD79Wz9AmYW1ZEMKrTU0TyjD.uASzP_JMyjcScSxI4R4CJeVt8f5Eu0wqQVZWYR YLv2uoOu76qbK9AZaqoagTYuEUS97GFBDtOP4F.A10410.9s5IO8OfTOIw1q0p_JDBhjP10wZDzE cCXNHxnOuKXHU1fXZ8hWpqEb3SoWwyK.Z9aTem3hcCct53nOrQqRSLD470FGsF4JcjfitXiWaA.0 s_ALzlcxdr.kknv54LgJuNp4q7UzqPJKquf5EhkJBikefhi3_V_XkcmQKtSVA3wat29.e46ZGPVJ iaZz2X1pXeTCzJDZIicNil6vgqJv70XOc67uPaFgOymrJfjpjjHZx5ab4wz5Mi164BR6Tf8gbrPR qYd4eZouqRL.Hm4r8zWnKwVaWGe1r9hWb0PBjhGSI.UGnI8ZeyJ47GsBmeSNmAruuCFmNrulg1fH Pk7.dfUTy7YY3zNLajIFyp2oSwQ7cwLrodKI32rFKzAbKmFP_RmdeV2OzEUnTzBai7yRaHgbg2Tq V1ysBsW7zl9AuP23UAtq6Y8JO.Q27_sl.WWYyx7.Lkir34LoTdQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 16 Oct 2018 16:15:07 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7360a7a2c5757fbe54d04f9602093439; Tue, 16 Oct 2018 16:15:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: GPL requirements vs. "some of which are compiled with GCC" terms in special exceptions? From: Mark Millard In-Reply-To: Date: Tue, 16 Oct 2018 09:15:02 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <113B9196-2951-477A-A508-FA0F8E5598AC@yahoo.com> References: <5449BAA6-E022-4DE4-870A-8AE132A6F9FA@yahoo.com> <61B6C299-2F93-4678-8928-3CABDFED6623@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 16:15:13 -0000 [WITH_LLVM_LIBUNWIND=3D is still broken for powerpc64 (and likely powerpc).] On 2018-Oct-13, at 7:54 PM, Mark Millard wrote: > On 2018-Oct-13, at 7:40 PM, Mark Millard wrote: >=20 >> On 2018-Oct-13, at 10:15 AM, David Chisnall = wrote: >>=20 >>> This is a known problem with the GCC runtime libraries. GCC 4.3 and = later have a much better exemption (which talks about any eligible = compilation process, rather than being compiled with GCC), but those are = GPLv3 and so unacceptable for FreeBSD. >>=20 >> I see. Good to know. >=20 > Hmm. As of head -r339076 the src.conf man page says: >=20 > WITHOUT_LLVM_LIBUNWIND > Set to use GCC's stack unwinder (instead of LLVM's = libunwind). >=20 > This is a default setting on arm/arm, arm/armv6, = arm/armv7, > powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and > sparc64/sparc64. >=20 > I believe arm/armv7, arm/armv6, and arm/arm are using clang for such > vintages: >=20 > WITH_CLANG_BOOTSTRAP > Set to build the Clang C/C++ compiler during the bootstrap = phase > of the build. >=20 > This is a default setting on amd64/amd64, arm/arm, = arm/armv6, > arm/armv7, arm64/aarch64 and i386/i386. >=20 >=20 > But may be the man page is just out of date for WITHOUT_LLVM_LIBUNWIND = ? >=20 >>> I don=E2=80=99t believe that we are using any of those files on = platforms where clang is the default system compiler. LLVM=E2=80=99s = libUnwind should be able to handle PowerPC on Linux, so it=E2=80=99s = worth checking if this is the case on FreeBSD. >>=20 >> Last I tried llvm's libunwind for powerpc64 was back in = 2016-Dec/2017-Jan. >> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 . = There was also >> the llvm submittal 31590. >>=20 >> I might try it again at some point. But clang and llvm have other = issues for >> use for buildworld buildkernel as well as I understand. (But I'm = doing some >> new experiments these days.) >>=20 >> I've no clue if llvm's libunwind is intended to be compliant with the >> powerpc64 and powerpc ABIs that FreeBSD bases itself on for the = powerpc >> family. >>=20 >>>> On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain = wrote: >>>>=20 >>>> While investigating powerpc64 C++ exception handling for >>>> builds under devel/powerpc64-gcc I ran into the following >>>> in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c : >>>>=20 >>>> /* As a special exception, if you link this library with other = files, >>>> some of which are compiled with GCC, to produce an executable, >>>> this library does not by itself cause the resulting executable >>>> to be covered by the GNU General Public License. >>>> This exception does not however invalidate any other reasons why >>>> the executable file might be covered by the GNU General Public = License. */ >>>>=20 >>>> So in contexts were clang/llvm is used to exclusion . . . are >>>> any such files in use? (I happen to be using devel/powerpc64-gcc at >>>> the moment.) >>>>=20 >>>> For me this has no real implications: I do not distribute >>>> my experiments. But I was surprised by what I read. >>>>=20 >>>> Looking I find: >>>>=20 >>>> # grep -r "some of which are compiled with GCC" /usr/src/* | more >>>> /usr/src/contrib/gcc/config/i386/gthr-win32.c: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/crtend.asm: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/fde-glibc.c: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/crtbegin.asm: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/lib1funcs.asm: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/crtfastmath.c: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/unwind-ia64.c: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/mips/mips16.S: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/vxlib.c: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/libgcc2.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-posix95.h: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-posix.h: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-posix.c: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gbl-ctors.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-gnat.c: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-rtems.h: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-vxworks.h: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-dce.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-nks.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-tpf.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-aix.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-lynx.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-solaris.h: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr.h: some of which are compiled with GCC, = to produce an executable, >>>> /usr/src/contrib/gcc/gcov-io.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-gnat.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-single.h: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-win32.h: some of which are compiled = with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/tsystem.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/typeclass.h: some of which are compiled with = GCC, to produce an executable, >>>> /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c: some of which are = compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/unwind-dw2-fde-darwin.c: some of which are = compiled with GCC, to produce an executable, >>>=20 >=20 As for using WITH_LLVM_LIBUNWIND=3D for powerpc64 with = devel/powerpc64-gcc based on the current build infrastructure and the notation in some of the files (simply adding the line to my alternately-named equivalent of src.conf for such a build): . . . GNU C99 (FreeBSD Ports Collection for powerpc64) version 6.4.0 = (powerpc64-unknown-freebsd12.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.1 = (tags/RELEASE_601/final 335540), GMP version 6.1.2, MPFR version 4.0.1, = MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 . . . --- UnwindRegistersRestore.o --- Using built-in specs. COLLECT_GCC=3D/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc Target: powerpc64-unknown-freebsd12.0 Configured with: = /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/configure = --target=3Dpowerpc64-unknown-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --enable-gnu-indirect-function = --without-headers --with-gmp=3D/usr/local --with-pkgversion=3D'FreeBSD = Ports Collection for powerpc64' --with-system-zlib = --with-gxx-include-dir=3D/usr/include/c++/v1/ --with-sysroot=3D/ = --with-as=3D/usr/bin/powerpc64-unknown-freebsd12.0-as = --with-ld=3D/usr/bin/powerpc64-unknown-freebsd12.0-ld = --enable-initfini-array --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --infodir=3D/usr/local/info/ = --build=3Dpowerpc64-unknown-freebsd12.0 Thread model: posix gcc version 6.4.0 (FreeBSD Ports Collection for powerpc64)=20 COLLECT_GCC_OPTIONS=3D'-gdwarf-2' '-B' = '/usr/local/powerpc64-unknown-freebsd12.0/bin/' '-O2' '-pipe' '-I' = '/usr/src/contrib/llvm/projects/libunwind/include' '-I' = '/usr/src/lib/libgcc_eh' '-D' '_LIBUNWIND_IS_NATIVE_ONLY' '-g' = '-std=3Dgnu99' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' = '-Wno-uninitialized' '-Wno-pointer-sign' '-Wno-error=3Daddress' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dattributes' = '-Wno-error=3Dbool-compare' '-Wno-error=3Dcast-align' = '-Wno-error=3Dclobbered' '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' = '-Wno-error=3Dinline' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dstrict-aliasing' '-Wno-error=3Duninitialized' = '-Wno-error=3Dunused-but-set-variable' '-Wno-error=3Dunused-function' = '-Wno-error=3Dunused-value' '-Wno-error=3Dmisleading-indentation' = '-Wno-error=3Dnonnull-compare' '-Wno-error=3Dshift-negative-value' = '-Wno-error=3Dtautological-compare' '-Wno-error=3Dunused-const-variable' = '-v' '-c' '-o' 'UnwindRegistersRestore.o' . . . --- UnwindRegistersRestore.o --- ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/../../../../powerp= c64-unknown-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: /usr/src/contrib/llvm/projects/libunwind/include /usr/src/lib/libgcc_eh /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include End of search list. . . . --- UnwindRegistersRestore.o --- /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S: = Assembler messages: = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:98: = Error: junk at end of line, first unrecognized character is `@' = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:98: = Error: junk at end of line, first unrecognized character is `@' = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:100:= Error: unrecognized opcode: `void' = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:102:= Error: unrecognized opcode: `on' = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:103:= Error: unrecognized opcode: `thread_state' = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:106:= Error: unrecognized opcode: `restore' = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:107:= Error: unrecognized opcode: `skip' = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:108:= Error: unrecognized opcode: `skip' = /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:110:= Error: unrecognized opcode: `skip' . . . (I will not list the long list of errors.) It appears that the file expects C-preprocessor handling that is not applied (#lines not treated as comments, #if defined(...) ignored): //=3D=3D=3D-------------------- UnwindRegistersRestore.S = ------------------------=3D=3D=3D// // // The LLVM Compiler Infrastructure // // This file is dual licensed under the MIT and the University of = Illinois Open // Source Licenses. See LICENSE.TXT for details. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #include "assembly.h" .text #if defined(__i386__) DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_x866jumptoEv) # # void libunwind::Registers_x86::jumpto() # # On entry: # + + # +-----------------------+ # + thread_state pointer + # +-----------------------+ # + return address + # +-----------------------+ <-- SP # + + movl 4(%esp), %eax # set up eax and ret on new stack location movl 28(%eax), %edx # edx holds new stack pointer subl $8,%edx movl %edx, 28(%eax) movl 0(%eax), %ebx movl %ebx, 0(%edx) movl 40(%eax), %ebx movl %ebx, 4(%edx) # we now have ret and eax pushed onto where new stack will be # restore all registers movl 4(%eax), %ebx movl 8(%eax), %ecx movl 12(%eax), %edx movl 16(%eax), %edi movl 20(%eax), %esi movl 24(%eax), %ebp movl 28(%eax), %esp # skip ss # skip eflags pop %eax # eax was already pushed on new stack ret # eip was already pushed on new stack # skip cs # skip ds # skip es # skip fs # skip gs . . . There is also the oddity of the __ppc__ code's notation: #elif defined(__ppc__) DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_ppc6jumptoEv) ; ; void libunwind::Registers_ppc::jumpto() ; ; On entry: ; thread_state pointer is in r3 ; ; restore integral registerrs ; skip r0 for now ; skip r1 for now lwz r2, 16(r3) ; skip r3 for now ; skip r4 for now ; skip r5 for now lwz r6, 32(r3) lwz r7, 36(r3) lwz r8, 40(r3) lwz r9, 44(r3) lwz r10, 48(r3) lwz r11, 52(r3) lwz r12, 56(r3) lwz r13, 60(r3) . . . Justin Hibbits wrote about this notation ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 comment 1 ): QUOTE The naked 'r*' and 'f*' register designations are a Darwinism. SysV = notation requires '%r*' and '%f*', or naked numbers. This should probably be filed upstream as well. END QUOTE This suggests that, for __ppc__, LLVM's libunwind is Darwin specific still. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Tue Oct 16 16:54:27 2018 Return-Path: Delivered-To: freebsd-toolchain@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 7F73A10DA6E2 for ; Tue, 16 Oct 2018 16:54:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 19ED7755E6 for ; Tue, 16 Oct 2018 16:54:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D141410DA6DD; Tue, 16 Oct 2018 16:54:26 +0000 (UTC) Delivered-To: toolchain@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 BF8B310DA6DC for ; Tue, 16 Oct 2018 16:54:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F84F755E1 for ; Tue, 16 Oct 2018 16:54:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A317065BD for ; Tue, 16 Oct 2018 16:54:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9GGsPnT004619 for ; Tue, 16 Oct 2018 16:54:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9GGsP9Y004618 for toolchain@FreeBSD.org; Tue, 16 Oct 2018 16:54:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 215039] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents Date: Tue, 16 Oct 2018 16:54:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 16:54:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 --- Comment #3 from Mark Millard --- Note: I recently posted to a list that the problems still exist as of head -r339076 . This was in reply to a suggestion to try it. But the particular experiment was adding WITH_LLVM_LIBUNWIND=3D to a src.conf type of file for using devel/powerpc64-gcc to do the build (on a powerpc64). [clang is still not up to it.] For example, UnwindRegistersRestore.S did not get the C-preprocessor handling that it is designed for and the __ppc__ assembler notation still has "register designations are a Darwinism" status. The ";" comment notation also might be a Darwinism as far as I know. WITH_LLVM_LIBUNWIND=3D is not yet an option for powerpc64 and the like. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Oct 16 16:55:53 2018 Return-Path: Delivered-To: freebsd-toolchain@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 7C93310DA797 for ; Tue, 16 Oct 2018 16:55:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 178EA75745 for ; Tue, 16 Oct 2018 16:55:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id CED2E10DA793; Tue, 16 Oct 2018 16:55:52 +0000 (UTC) Delivered-To: toolchain@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 BD3F910DA792 for ; Tue, 16 Oct 2018 16:55:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CA147573F for ; Tue, 16 Oct 2018 16:55:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A6D1065BF for ; Tue, 16 Oct 2018 16:55:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9GGtpdV006126 for ; Tue, 16 Oct 2018 16:55:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9GGtpDu006125 for toolchain@FreeBSD.org; Tue, 16 Oct 2018 16:55:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 215039] head -r339076 TARGET_ARCH=powerpc64 clang 6.0.1 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents Date: Tue, 16 Oct 2018 16:55:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 16:55:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|head -r309179 |head -r339076 |TARGET_ARCH=3Dpowerpc64 clang |TARGET_ARCH=3Dpowerpc64 = clang |3.9.0 based buildworld on |6.0.1 based buildworld on |powerpc64 using |powerpc64 using |WITH_LLVM_LIBUNWIND=3D fails |WITH_LLVM_LIBUNWIND=3D f= ails |to build: asserts and |to build: asserts and |rejects .S file contents |rejects .S file contents --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Oct 16 22:29:56 2018 Return-Path: Delivered-To: freebsd-toolchain@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 2D57C10E3B46 for ; Tue, 16 Oct 2018 22:29:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.ne1.yahoo.com (sonic314-21.consmr.mail.ne1.yahoo.com [66.163.189.147]) (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 A806282EE3 for ; Tue, 16 Oct 2018 22:29:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: H3tKvo8VM1lL61yMh6CAH_DAz0RjTyHGHoAL3Cl41607ETYPC6GQ4Ay.ZiIddB3 lwDmt6xgyj1vd27RIk_uht3rn2WaTSqkjfIlNGCS2h1fOkH16zcXkwkQE4Nab4QZU3yrfLhON7I9 fPRzZxgv_XdMMKaHoE7A1y9Gq3UmCuguJtgU0qkOeuGBjosvCbK.8_JlrkfPDogmAJmgKAWgguZp CTf_j3qBWQT77b3yTwWZH9KjTMvwNPFPA9hT5rW.ntq.mf8eKpvdVMefPATec02BFPCXGzFUvo.g 3QAOuuiMgsl5BhAhcgunQ50kG0mBLbFYbE62ts8P7ZLzT6193MBbsTFIeZcSVaprvDA9uWKMokQ4 SonwpY1ctf95rU7f7roYBa5MQ4VgT0SjJRWa1rlQtInql9SRVNbfCUSO11bqOZDSdVzwiuKQ9iD5 IyJ1QMNpfHVW.AqAAxq_YYEO4Ut3NYR2piJhtmsLXlvSbGX99Lf8jS5n6ztnwjNcCLsAgrfMKFAx Bh45DK4JA6Vj3a.VuvscMmUVG8x0Qafbz1MaHB_XkvBonwKefZ8FrB2gDvWaJ3z7i2Bc_WRE5sPA 2NJ_LICzvuWO1flzNOxVW9368VA4ldM90BdwjN_BwbBtxFfKQqxU3kLNFVzOx5BSfkEvrdVNmtf1 FWZuEgB2.u3Kd_t1NgWPYLEK6vXOweuKvWT65QJubcE3TKgiGmfdDsAWkiScalJZHu_KEhopJqUh bfN13MlcezuRAQAPtm4wcAOSZ1chlKeKyJ.iQ5jVIozGT8YVI6LfoSljXOpOxOhQIyUwzNh6oCkp BnbFqGyZjjij9SdI4ziNf.dSpFVI19xxF..WAKbDAnYzTLaix.zmctf_E04UOlIAcCktfhafISrF DXpcsQie2tVifS2dXLqWBtfUONWm7y.FC_IaYFQHCISddhjO5CZ8Kphp_L2uEIg.5obJlX5fw0kp Qca3bLjPnNU.Yw1qjrFvYAnprzJ_cZhBlXHEvuKC_9cFMx6zHf9rwnVFAumuU5pjec_oQw5HEBFJ z3HTRXahguBEb.kkXixI3DE4x_zrprV7EM_YG1hB475iqsKySkvKeIzXuXonh4VPFaNdGYaARzmZ o6SHQABNiz3SjrVga7Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Tue, 16 Oct 2018 22:29:48 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 513438678ecee606fe797d481f79ca2e; Tue, 16 Oct 2018 22:29:46 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: How to get devel/powerpc-gcc based WITH_LIBCPLUSPLUS= buildworld to have some throwing of C++ exceptions work (patch) Message-Id: <86E4687B-280A-4625-A56E-8D6FC4C4675B@yahoo.com> Date: Tue, 16 Oct 2018 15:29:45 -0700 Cc: Justin Hibbits To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 22:29:56 -0000 I now have a patch that gets some basic C++ exception throwing going for WITH_LIBCPLUSPLUS=3D use when building via devel/powerpc64-gcc . But the overall mechanism seems to mess up the handling of powerpc64's "red zone" style of stack processing in various cases. I've had recent list submittals reporting that buildworld using WITH_LIBCPLUSPLUS=3D based on devel/powerpc64-gcc would get stuck looping in _Unwind_RaiseException. This prevented use of devel/gdb --which makes extensive use of throwing C++ exceptions in normal operation. Well, I now have a patch that avoids the problem in libcxxrt's throw_exception itself that made all throws get stuck --and so allows some C++ exceptions to be thrown. See below. (I'm not sure leading spaces will all be preserved.) Most of text is commentary, not code. # svnlite diff /usr/src/contrib/libcxxrt/ Index: /usr/src/contrib/libcxxrt/exception.cc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/libcxxrt/exception.cc (revision 339076) +++ /usr/src/contrib/libcxxrt/exception.cc (working copy) @@ -772,10 +772,71 @@ info->globals.uncaughtExceptions++; =20 _Unwind_Reason_Code err =3D = _Unwind_RaiseException(&ex->unwindHeader); +#if !defined(__powerpc64__) && !defined(__ppc64__) // The _Unwind_RaiseException() function should not return, it = should // unwind the stack past this function. If it does return, then = something // has gone wrong. report_failure(err, ex); +#else +// NOTE: Only tested for devel/powerpc64-gcc based buildworld +// because clang still silently ignores +// __builtin_eh_return(offset,handler) for powerpc64 +// (and powerpc), thus not generating correct output. +// +// NOTE: I've no clue if other archtiectures might have +// analogous issues to powerpc64. I'm not sure +// about powerpc because of it still being stuck +// at gcc 4.2.1 . (clang problems and no devel/powerpc-gcc .) +// +// The above/normal code produced the following sort of structure +// for throw_exception. r1 is the stack pointer, note its adjustments +// via stdu r1,-128(r1) and via addi r1,r1,128 . +// +// : mflr r0 +// : std r31,-8(r1) +// : mr r31,r3 +// : std r0,16(r1) +// : stdu r1,-128(r1) +// . . . +// : bl = <00000018.plt_call._Unwind_RaiseException@@GCC_3.0> +// : ld r2,40(r1) +// : addi r1,r1,128 +// : mr r4,r31 +// : ld r0,16(r1) +// : ld r31,-8(r1) +// : mtlr r0 +// : b +// +// The loop in __Unwind_RaiseException had its "fs" +// used with uw_frame_state_for and uw_update_context get +// stuck with the pc field having the address for +// throw_exception+152 (just after the stack adjustment +// addi r1,r1,128). Effectively, throw_exception unwinds +// its stack use before calling report_failure in a +// way that throw_exception is no longer on the stack. +// The exception unwinding logic did not handle this +// correctly and got stuck looping. +// +// The below avoids having any such stack adjustment here +// by avoiding the report_failure call and directly doing +// what case _URC_END_OF_STACK in report_failure does for +// its first couple of lines. (It is also the kind of +// thing that src/contrib/libstdc++/libsupc++/eh_throw.cc +// has in its __cxxabiv1::__cxa_throw after the +// _Unwind_RaiseException call.) +// +// Another option could be to turn report_failure into +// a macro so that no subroutine call could be involved. +// That should avoid the early stack pointer kadjsutment. +// +// Also: For the other archtiectures that I looked at, no +// such stack adjsutments were involved in the code +// generated (or the matching dwarfdump output). +// But I did not look at many. + + __cxa_begin_catch (&(ex->unwindHeader)); + std::terminate(); +#endif } =20 =20 However, code such as the following from devel/kyua leads to other examples of _Unwind_RaiseException looping without making progress. Note the stdu r1,-368(r1) and the addi r1,r1,368 stack pointer adjustments and their timing relative to stack usage (the "red zone" style used for FreeBSD's powerpc64 ABI): (gdb) x/64i 0x100a8528-88 0x100a84d0 : mflr = r0 0x100a84d4 : = std r30,-16(r1) 0x100a84d8 : = std r31,-8(r1) 0x100a84dc : = std r29,-24(r1) 0x100a84e0 : = mr r31,r4 0x100a84e4 : = std r0,16(r1) 0x100a84e8 : = stdu r1,-368(r1) 0x100a84ec : = mr r30,r3 0x100a84f0 : = bl 0x100abab0 0x100a84f4 : = nop 0x100a84f8 : = clrlwi r4,r31,16 0x100a84fc : = bl 0x10009fc0 <000000af.plt_call.mkdir@@FBSD_1.0> 0x100a8500 : = ld r2,40(r1) 0x100a8504 : = cmpwi cr7,r3,-1 0x100a8508 : = beq cr7,0x100a8528 0x100a850c : = addi r1,r1,368 0x100a8510 : = ld r0,16(r1) 0x100a8514 : = ld r29,-24(r1) 0x100a8518 : = ld r30,-16(r1) 0x100a851c : = ld r31,-8(r1) 0x100a8520 : = mtlr r0 0x100a8524 : = blr 0x100a8528 : = bl 0x10009d40 <000000af.plt_call.__error@@FBSD_1.0> . . . (more not shown here) . . . This goes along with (darfdump -v -v -F output): < 1323><0x100a84d0:0x100a8670> 0x100a84d0: =20 0x100a84e0: =20 0x100a84ec: =20 0x100a8510: =20 0x100a8524: =20 0x100a8528: =20 fde section offset 62424 0x0000f3d8 cie offset for fde: 61696 = 0x0000f100 0 DW_CFA_advance_loc 16 (4 * 4) 1 DW_CFA_register r65 =3D r0 4 DW_CFA_offset r30 -16 (2 * -8) 6 DW_CFA_offset r31 -8 (1 * -8) 8 DW_CFA_offset r29 -24 (3 * -8) 10 DW_CFA_advance_loc 12 (3 * 4) 11 DW_CFA_def_cfa_offset 368 14 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 17 DW_CFA_advance_loc 36 (9 * 4) 18 DW_CFA_remember_state 19 DW_CFA_def_cfa_offset 0 21 DW_CFA_advance_loc 20 (5 * 4) 22 DW_CFA_restore_extended r65 24 DW_CFA_restore r31 25 DW_CFA_restore r30 26 DW_CFA_restore r29 27 DW_CFA_advance_loc 4 (1 * 4) 28 DW_CFA_restore_state 29 DW_CFA_nop 30 DW_CFA_nop The _Unwind_RaiseException's fs ends up reaching and the holding the following value in my attempted devel/kyua run for FreeBSD's test suite: (gdb) print fs $9 =3D {regs =3D {reg =3D {{loc =3D {reg =3D 0, offset =3D 0, exp =3D = 0x0}, how =3D REG_UNSAVED} , {loc =3D {reg =3D = 18446744073709551592, offset =3D -24,=20 exp =3D 0xffffffffffffffe8 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D= 18446744073709551600, offset =3D -16,=20 exp =3D 0xfffffffffffffff0 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D= 18446744073709551608, offset =3D -8,=20 exp =3D 0xfffffffffffffff8 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D= 0, offset =3D 0, exp =3D 0x0},=20 how =3D REG_UNSAVED} , {loc =3D {reg =3D 16, = offset =3D 16, exp =3D 0x10 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D 0, offset =3D 0,=20 exp =3D 0x0}, how =3D REG_UNSAVED} }, prev =3D= 0x0}, cfa_offset =3D 0, cfa_reg =3D 1, cfa_exp =3D 0x0, cfa_how =3D = CFA_REG_OFFSET,=20 pc =3D 0x100a8528 ,=20= personality =3D @0x810549c40: 0x81053c900 <__gxx_personality_v0(int, = _Unwind_Action, uint64_t, _Unwind_Exception*, _Unwind_Context*)>, = data_align =3D -8, code_align =3D 4, retaddr_column =3D 65,=20 fde_encoding =3D 27 '\033', lsda_encoding =3D 20 '\024', saw_z =3D 1 = '\001', signal_frame =3D 0 '\000', eh_ptr =3D 0x0} Note the invariant value it is looping with (fs.pc value): pc =3D 0x100a8528 But the routine is at 0x00000000100a85ec : (gdb) bt #0 _Unwind_RaiseException (exc=3D0x8109582e0) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:103 #1 0x000000081053d704 in throw_exception (ex=3D0x810958288) at = /usr/src/contrib/libcxxrt/exception.cc:774 #2 0x00000000100a85ec in utils::fs::mkdir (dir=3D..., = mode=3Dmode@entry=3D493) at utils/fs/operations.cpp:484 #3 0x00000000100a8694 in utils::fs::mkdir_p (dir=3D..., mode=3D) at utils/fs/operations.cpp:502 #4 0x000000001000cbf4 in (anonymous namespace)::safe_main = (mock_command=3D..., argv=3D0x3fffffffffffdb88, argc=3D4, = ui=3D0x3fffffffffffd960, this=3D, this=3D) = at cli/main.cpp:207 #5 cli::main (ui=3Dui@entry=3D0x3fffffffffffd960, argc=3Dargc@entry=3D4, = argv=3Dargv@entry=3D0x3fffffffffffdb88, mock_command=3D...) at = cli/main.cpp:280 #6 0x000000001000e9dc in cli::main (argc=3D, = argv=3D0x3fffffffffffdb88) at cli/main.cpp:353 #7 0x000000001000c570 in main (argc=3D, argv=3D) at main.cpp:49 where utils::fs::mkdir: 0x00000000100a85d0 <+256>: bne 0x100a85f0 = 0x00000000100a85d4 <+260>: addis r9,r2,-1 0x00000000100a85d8 <+264>: addis r10,r2,-1 0x00000000100a85dc <+268>: mr r3,r29 0x00000000100a85e0 <+272>: addi r5,r9,20864 0x00000000100a85e4 <+276>: addi r4,r10,-12216 0x00000000100a85e8 <+280>: bl 0x1000a140 = <000000af.plt_call.__cxa_throw@@CXXABI_1.3> =3D> 0x00000000100a85ec <+284>: ld r2,40(r1) 0x00000000100a85f0 <+288>: ld r3,320(r1) 0x00000000100a85f4 <+292>: bl 0x1000a8c0 = <000000af.plt_call._ZdlPv> 0x00000000100a85f8 <+296>: ld r2,40(r1) 0x00000000100a85fc <+300>: b 0x100a85d4 = This is for the devel/kyua code: void fs::mkdir(const fs::path& dir, const int mode) { if (::mkdir(dir.c_str(), static_cast< mode_t >(mode)) =3D=3D -1) { const int original_errno =3D errno; throw fs::system_error(F("Failed to create directory %s") % dir, original_errno); } } I've not figured out how to make general throwing of C++ exceptions avoid this _Unwind_RaiseException unbounded looping with a fixed fs.pc value. But at least now I can use devel/gdb for some of the investigation's activity. Other notes: WITH_LLVM_LIBUNWIND=3D does not even compile for targeting powerpc64 --so that is not currently a way around the problem. WITHOUT_LIB32=3D yse is because, for every post-gcc 4.2.1 that I've tried, the lib32 produced misuses R30 in crtbeginS code (vs. the ABI for FreeBSD) and 32-bit code just produces core files from a bad so-called address that is dereferenced via R30 content. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Wed Oct 17 08:41:29 2018 Return-Path: Delivered-To: freebsd-toolchain@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 A88B710CDDAC for ; Wed, 17 Oct 2018 08:41:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6635F76CDF for ; Wed, 17 Oct 2018 08:41:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 27CEE10CDDA3; Wed, 17 Oct 2018 08:41:29 +0000 (UTC) Delivered-To: toolchain@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 16BD610CDDA2 for ; Wed, 17 Oct 2018 08:41:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC38476CD4 for ; Wed, 17 Oct 2018 08:41:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id F3EFC16B62 for ; Wed, 17 Oct 2018 08:41:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9H8fRGb078083 for ; Wed, 17 Oct 2018 08:41:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9H8fRlI078077 for toolchain@FreeBSD.org; Wed, 17 Oct 2018 08:41:27 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230857] loading carp module panic i386 kernel (VIMAGE related) Date: Wed, 17 Oct 2018 08:41:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: panic, toolchain, vimage X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bz@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: dependson Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 08:41:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230857 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |232291, 232289 --- Comment #8 from Bjoern A. Zeeb --- Track the dependency problems; need to solve at least the link_elf one bef= ore we can do the BYTE(1) linker script and follow-up link_elf checks. Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232289 [Bug 232289] kern/link_elf.c fails for small sections sizes ( Delivered-To: freebsd-toolchain@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 1A68510D03ED for ; Wed, 17 Oct 2018 10:00:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com [74.6.128.82]) (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 B39AD7A001 for ; Wed, 17 Oct 2018 10:00:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: lj3DrygVM1loCiK1nJl0qzBV9C7DR93JYWzQuICiHW5eOr3RPSrmmwVqIkGk7Ed Pd0QcZHUZmBlE8GvI8I2OJd6uX.kHMeBJu3129C1oJwETOXNxd7ATit7nPsqpH5qxro98mjoddF7 a2YeDO5xNOvKchvetxS6O3emKOWLz_GplLVRM9ftc5QaVXWhZ.DG919S3_mmRdpRerYtoa4bgv2T xQ1Xeib_OMD8bXlTT_v4v7A1gLbbUDVN2tyvqX7iKyEHWkNjLlMgpNZM6Rq3dGDNxfaygkMCo.JE EHc980a0fa7z2QmIVnBdTj1bwjr2OdAKDeID217wGx6oddxVOYZdebTttWE.EaA9ff2m6uu880Tg gG7U5I3p64ZgRbPz5ildOnhrLvaRnSm_dXMUZxJX1y4RLUlrRcpjrpQRhAjSHYMP1845lCx9Jcdt QBe6HAFmqohoSiV11TerE_JdnN3EnObyMTe.8.UkaY3sL3cCmax5ZK0lLWvtQFnIiSWIbsBwnOmN q340PFUk3qN5Z5ChlYK4DbmZKwHtYOOrdmosLnm8pIDBMKo9n78ttC54dnLPK8rtYvKCUU_A_8as q7uZTxHYU1CBNxVNAqxvdrq6fHOlFBoxdByLh8VianBzVO_75CC6oS26R5qwVfD4AND3fEJqVAQX qNUyvwWmOcOKJQQfBFpyMehYe.qVzO2l3HuObLWM60IvYt3gMaWaABfx4UCkx7nwjwTVPflOxlrF 8444mJUFyGSF.pDhe8D7h8U5.r7hODbTWmr9A00AMaDMxzuYoBsmwOKKgLBphjOru1jdfusNuPLg .PyX.y8CMO.2Z3HC.JIw01mrX8BMdG8sritfRHQjY12.qaOMf15qLE7fLitYbdESZR3lvqPPKOEZ TLO7gvRS4EhsTLt0lstGUw57RuZwsHLrkiZovM7NlfsxM75kbUdy0zZCsiQGsYiZnYx0NW0jJUAo uslixYASSVQS5Vbu1MHAtxAFC5jzp0LiBqYeJi8i_M.ZZsOF9HI4sMrji0F0sf_KVlbQrOyIH8_3 sZEl2Br.2atceKMnOUtnb9fWPJlUlqpqucmrr83lXwDvuYHXyo8DmyzQHMnzaABHDiWINGSht_f7 NJpuv0JOiltqRpOxmBw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Oct 2018 09:59:56 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 262adbda998196774548452c497e7325; Wed, 17 Oct 2018 09:59:54 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: /lib/libgcc_s.so.1 mishandles eh_frame information that /usr/local/lib/gcc8/libgcc_s.so.1 handles (powerpc64 test context): a simple example program Message-Id: <4D444DB3-A472-42BC-973E-3E468C07757B@yahoo.com> Date: Wed, 17 Oct 2018 02:59:51 -0700 Cc: Justin Hibbits To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 10:00:03 -0000 (I happen to be using head -r339076 and ports -r480180 vintage materials, not that I expect such narrow vintage ties.) I finally have a simple example of the issue on powerpc64 . . . The following simple C++ program shows a significant difference for powerpc64 depending on which libgcc_s.so is used (system's vs. gcc8's): # more exception_test1.cpp=20 #include // -O2 context used. volatile unsigned int v =3D 1; extern int f() { volatile unsigned char c =3D 'a'; v++; // Despite "volatile" the access to v in g // was otherwise optimized out and the // std::exception was not followed by // code for f(). So force g's use. return c; } extern void g() { if (v) throw std::exception(); f(); // ends up inlined but the problem is demonstrated. } int main(void) { try {g();} // Used a separate function to avoid any potential // special handling of code in main. Call not // optimized out. catch (std::exception& e) {} return 0; } (gcc8 just happens to be the lang/gcc* that I have installed. Similar points likely apply to gcc[?-8]. The same problem can be demonstrated by devel/powerpc64-gcc use, which ends up using /lib/libgcc_s.so.1 as well --but does not provide the contrasting "it works" case.) The only reason for the try/catch is to avoid the "it works" case from doing: # ./a.out terminate called after throwing an instance of 'std::exception' what(): std::exception Abort trap (core dumped) Just calling g() is enough to have the problem with /lib/libgcc_s.so.1 . The program works fine for being built via: # g++8 -Wl,-rpath=3D/usr/local/lib/gcc8 -g -O2 exception_test1.cpp # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc8/libstdc++.so.6 = (0x81006e000) libm.so.5 =3D> /lib/libm.so.5 (0x8102c7000) libgcc_s.so.1 =3D> /usr/local/lib/gcc8/libgcc_s.so.1 = (0x810307000) libc.so.7 =3D> /lib/libc.so.7 (0x810330000) But fails, stuck looping in _Unwind_RaiseException, for being built via: # g++8 -g -O2 exception_test1.cpp # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc8/libstdc++.so.6 = (0x81006e000) libm.so.5 =3D> /lib/libm.so.5 (0x8102c7000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810307000) libc.so.7 =3D> /lib/libc.so.7 (0x81032d000) The only difference (other than detailed addresses) is: libgcc_s.so.1 =3D> /usr/local/lib/gcc8/libgcc_s.so.1 = (0x810307000) vs. libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810307000) The dwarfdump -v -v -F reports match exactly for the two builds of the program, as does the code for the function g where the problem is observed. What is different is that /lib/libgcc_s.so.1 misinterprets the .eh_frame information (disagreeing with the dwarfdump report and with /usr/local/lib/gcc8/libgcc_s.so.1 behavior). # dwarfdump -v -v -F a.out | more .eh_frame fde: < 0><0x100007a0:0x10000840><> 0x100007a0: =20 fde section offset 20 0x00000014 cie offset for fde: 24 0x00000018 0 DW_CFA_nop 1 DW_CFA_nop 2 DW_CFA_nop < 1><0x10000840:0x10000894>
0x10000840: =20 0x1000084c: =20 0x10000854: =20 0x10000860: =20 0x10000864: =20 fde section offset 152 0x00000098 cie offset for fde: 36 0x00000024 0 DW_CFA_advance_loc 12 (3 * 4) 1 DW_CFA_def_cfa_offset 112 3 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 6 DW_CFA_advance_loc 8 (2 * 4) 7 DW_CFA_remember_state 8 DW_CFA_def_cfa_offset 0 10 DW_CFA_advance_loc 12 (3 * 4) 11 DW_CFA_restore_extended r65 13 DW_CFA_advance_loc 4 (1 * 4) 14 DW_CFA_restore_state < 2><0x10000db0:0x10000ddc> 0x10000db0: =20 fde section offset 64 0x00000040 cie offset for fde: 68 0x00000044 0 DW_CFA_nop 1 DW_CFA_nop 2 DW_CFA_nop < 3><0x10000de0:0x10000e5c> 0x10000de0: =20 0x10000de8: =20 0x10000e14: =20 0x10000e18: =20 0x10000e1c: =20 0x10000e24: =20 fde section offset 84 0x00000054 cie offset for fde: 88 0x00000058 0 DW_CFA_advance_loc 8 (2 * 4) 1 DW_CFA_def_cfa_offset 128 4 DW_CFA_advance_loc 44 (11 * 4) 5 DW_CFA_remember_state 6 DW_CFA_def_cfa_offset 0 8 DW_CFA_advance_loc 4 (1 * 4) 9 DW_CFA_restore_state 10 DW_CFA_advance_loc 4 (1 * 4) 11 DW_CFA_register r65 =3D r0 14 DW_CFA_advance_loc 8 (2 * 4) 15 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 18 DW_CFA_nop < 4><0x10000ee0:0x10000f34><> 0x10000ee0: =20 0x10000ee4: =20 0x10000ef8: =20 fde section offset 40 0x00000028 cie offset for fde: 44 0x0000002c 0 DW_CFA_advance_loc 4 (1 * 4) 1 DW_CFA_register r65 =3D r12 4 DW_CFA_advance_loc 20 (5 * 4) 5 DW_CFA_restore_extended r65 cie: < 0> version 1 cie section offset 0 0x00000000 augmentation zR code_alignment_factor 4 data_alignment_factor -8 return_address_register 65 eh aug data len 0x1 bytes 0x1b=20 bytes of initial instructions 3 cie length 16 initial instructions 0 DW_CFA_def_cfa r1 0 < 1> version 1 cie section offset 120 0x00000078 augmentation zPLR code_alignment_factor 4 data_alignment_factor -8 return_address_register 65 eh aug data len 0xb bytes 0x94 00 00 00 00 00 01 04 c9 14 1b=20 bytes of initial instructions 3 cie length 28 initial instructions 0 DW_CFA_def_cfa r1 0 In: < 3><0x10000de0:0x10000e5c> 0x10000de0: =20 0x10000de8: =20 0x10000e14: =20 0x10000e18: =20 0x10000e1c: =20 0x10000e24: =20 The last 3 128's are from the DW_CFA_restore_state from the sequence: 1 DW_CFA_def_cfa_offset 128 . . . 5 DW_CFA_remember_state . . . 9 DW_CFA_restore_state But with /lib/libgcc_s.so.1 the 128 is not saved and restored, leaving default 0's in place instead. And use of the wrong stack addresses results, which in turn prevents the stack from unwinding past g()'s frame. [Note: For FreeBSD on powerpc64 r1 is the stack-pointer.] The code described by the: < 3><0x10000de0:0x10000e5c> . . . is as follows. Note the stdu r1,-128(r1) and the addi r1,r1,128 and what code only used via bne cr7,0x10000e18 and that it has the stdu r1,-128(r1) prior context, not addi r1,r1,128: (gdb) disass g Dump of assembler code for function g(): 0x0000000010000de0 <+0>: nop 0x0000000010000de4 <+4>: stdu r1,-128(r1) 0x0000000010000de8 <+8>: lwz r9,-32536(r2) 0x0000000010000dec <+12>: cmpdi cr7,r9,0 0x0000000010000df0 <+16>: bne cr7,0x10000e18 0x0000000010000df4 <+20>: li r9,97 0x0000000010000df8 <+24>: nop 0x0000000010000dfc <+28>: stb r9,112(r1) 0x0000000010000e00 <+32>: lwz r9,-32536(r2) 0x0000000010000e04 <+36>: addi r9,r9,1 0x0000000010000e08 <+40>: stw r9,-32536(r2) 0x0000000010000e0c <+44>: lbz r9,112(r1) 0x0000000010000e10 <+48>: addi r1,r1,128 0x0000000010000e14 <+52>: blr 0x0000000010000e18 <+56>: mflr r0 0x0000000010000e1c <+60>: li r3,8 0x0000000010000e20 <+64>: std r0,144(r1) 0x0000000010000e24 <+68>: bl 0x100007a0 = <0000004b.plt_call.__cxa_allocate_exception@@CXXABI_1.3> 0x0000000010000e28 <+72>: ld r2,40(r1) 0x0000000010000e2c <+76>: nop 0x0000000010000e30 <+80>: nop 0x0000000010000e34 <+84>: ld r9,-32720(r2) 0x0000000010000e38 <+88>: ld r5,-32712(r2) 0x0000000010000e3c <+92>: nop 0x0000000010000e40 <+96>: ld r4,-32704(r2) 0x0000000010000e44 <+100>: std r9,0(r3) 0x0000000010000e48 <+104>: bl 0x10000820 = <0000004b.plt_call.__cxa_throw@@CXXABI_1.3> 0x0000000010000e4c <+108>: ld r2,40(r1) 0x0000000010000e50 <+112>: .long 0x0 0x0000000010000e54 <+116>: .long 0x90001 0x0000000010000e58 <+120>: lwz r0,0(0) [Note: more than the 128's might not be handled right for more general code, but the example only shows the 128's issue (i.e., the cfa_offset mishandling issue).] I'll note that throw_exception in /lib/libgcc_s.so.1 has the same sort of machine-code structure as g relative to cfa_offset's and that, without a workaround to avoid that structure being generated, all thrown C++ exceptions fail by _Unwind_RaiseException being stuck in a loop for powerpc64. In order to test the simple program I used the workaround: # svnlite diff /usr/src/contrib/libcxxrt/ Index: /usr/src/contrib/libcxxrt/exception.cc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/libcxxrt/exception.cc (revision 339076) +++ /usr/src/contrib/libcxxrt/exception.cc (working copy) @@ -772,10 +772,71 @@ info->globals.uncaughtExceptions++; _Unwind_Reason_Code err =3D = _Unwind_RaiseException(&ex->unwindHeader); +#if !defined(__powerpc64__) && !defined(__ppc64__) // The _Unwind_RaiseException() function should not return, it = should // unwind the stack past this function. If it does return, then = something // has gone wrong. report_failure(err, ex); +#else +// NOTE: Only tested for devel/powerpc64-gcc based buildworld +// because clang still silently ignores +// __builtin_eh_return(offset,handler) for powerpc64 +// (and powerpc), thus not generating correct output. +// +// NOTE: I've no clue if other archtiectures might have +// analogous issues to powerpc64. I'm not sure +// about powerpc because of it still being stuck +// at gcc 4.2.1 . (clang problems and no devel/powerpc-gcc .) +// +// The above/normal code produced the following sort of structure +// for throw_exception. r1 is the stack pointer, note its adjustments +// via stdu r1,-128(r1) and via addi r1,r1,128 . +// +// : mflr r0 +// : std r31,-8(r1) +// : mr r31,r3 +// : std r0,16(r1) +// : stdu r1,-128(r1) +// . . . +// : bl = <00000018.plt_call._Unwind_RaiseException@@GCC_3.0> +// : ld r2,40(r1) +// : addi r1,r1,128 +// : mr r4,r31 +// : ld r0,16(r1) +// : ld r31,-8(r1) +// : mtlr r0 +// : b +// +// The loop in __Unwind_RaiseException had its "fs" +// used with uw_frame_state_for and uw_update_context get +// stuck with the pc field having the address for +// throw_exception+152 (just after the stack adjustment +// addi r1,r1,128). Effectively, throw_exception unwinds +// its stack use before calling report_failure in a +// way that throw_exception is no longer on the stack. +// The exception unwinding logic did not handle this +// correctly and got stuck looping. +// +// The below avoids having any such stack adjustment here +// by avoiding the report_failure call and directly doing +// what case _URC_END_OF_STACK in report_failure does for +// its first couple of lines. (It is also the kind of +// thing that src/contrib/libstdc++/libsupc++/eh_throw.cc +// has in its __cxxabiv1::__cxa_throw after the +// _Unwind_RaiseException call.) +// +// Another option could be to turn report_failure into +// a macro so that no subroutine call could be involved. +// That should avoid the early stack pointer kadjsutment. +// +// Also: For the other archtiectures that I looked at, no +// such stack adjsutments were involved in the code +// generated (or the matching dwarfdump output). +// But I did not look at many. + + __cxa_begin_catch (&(ex->unwindHeader)); + std::terminate(); +#endif } =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Wed Oct 17 20:25:49 2018 Return-Path: Delivered-To: freebsd-toolchain@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 92D6D10DE803 for ; Wed, 17 Oct 2018 20:25:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.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 092E8905D4 for ; Wed, 17 Oct 2018 20:25:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .17zpVUVM1mNnfw6qZnnlw061.Segc8FdcVUgNsvTmB9z6anzaXPsRxzu.xUlWG XoykGuRCrwNL0IpO90jz27_P3TFPN9lLo7HRFoBWQVpXmz7Yd6WfYkXvtjCexuDIzNKyUW0ucnkO OBAnbi4xXmqsDGTcLVfe4lc7CW90AyQPvGnVrxJGSVCQxTSBKX2j7723LSPb5dBOcF0bi7vHs7x2 dD6KRV.mrt8tR.m6ki7PMkCWqzyOUIt_wXUUslaUcpE5aGbIJS92M.CXPybvCePGE0646iFSu_ka giF0dGnTpUD5fw6Hi.6i1kP4rPBx7ZJeRxLpS4cBgdNW3iciKzzDmapspgPWsP0CHn.9jqVN9JKB 64Vv3xWglFOOvTnYEQUgnV_LGHm9SFFWBCEGjI.1Vqjl5tYnzDq816F0FngxTJqbK_Bx9eOHha1e 2tdJ_PIJNj6V3pxEsDQZ12D8E2HDuF7Ix2E8RkTMPHDVOB2R9rMQXWRaw9jxJECUUAuc7Ul27iYG plKsEYS2L_bLTdVORUnPFDqUfx6XHJ9aXvLW2uJRe76pc6MKxevZnIxACvEiB9tQBQIKsZFQswJo 3bRnmyvPRzzyVwP0he80jLvT4MXIe6Fsg2GTyO4fiYolX07fig1KnIZYq27HhbxlJC_P4k1._FlZ L0HtMQTHGGr9ggWvww7w7mYe0ecyEGxq4Q8moct1WsQWhrOf4rxGCLIfZWnu75P5MGvLVAvkVNCO DpSa01D8nx44xnRoMQA1gpMuW5G2_OUbLLRLeKUfKyEeysslm4fSmF__JtdzYKXN9QnJ6YWfgB1C 9Ea1mApJvKPxEqbViksKSxu7ZzTSUlOXBX4sXkgzBIVEGshktXq2v644DcxnIUzfdDGLia6WS_zw aZhT9rj8cjy48hIFaa7YlSjRQWLT938oSOcdFNuRkv2KgHIudc1o5mXC4Q6Eh.sp6nNxWIzboF2x CLPkdN8PcPbSfJpl.GfEXSE4Sz3IhNfLGXLQzk6UG9AMiopmJFbsZsDW7oHJSaRwtPZT.uKAjfBy jgtyAU_d4.ohptH4OsDwIYIdQbRjLTU9gEoGmIIucszgdt0YlN6oYYz6en_sMqVzPbMeowXQX9iV LMhA3zBqH9RSen_4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Oct 2018 20:25:42 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 80e922adb91863636bdf56988756cc64; Wed, 17 Oct 2018 20:25:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: What is incomplete for /lib/libgcc_s.so-based C++ exception handling (where WITH_LLVM_LIBUNWIND= and /usr/local/lib/gcc*/libgcc_s.so are not used) Message-Id: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> Date: Wed, 17 Oct 2018 13:25:39 -0700 Cc: FreeBSD PowerPC ML To: FreeBSD Toolchain , FreeBSD , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 20:25:49 -0000 [This summarizes other results without the code and debugger evidence and such from my recent explorations. It should be much easier to follow than my exploration reports.] Documents like DWARF5.pdf document the "row" vs. Location information for Call Frame Information as (also used for .eh_frame like materials for C++ exception handling): (CFA: Cannonical Frame Address) QUOTE ("Structure of Call Frame Information") LOC CFA R0 R1...RN L0 L1 ... LN END QUOTE Note that the CFA is conceptually one of the registers in each row, even though it is not a machine register but a way to calculate the conceptual register's value from machine registers. The information for the machine registers are typically based on the earlier CFA value (from the same row!). Absent a correct CFA cell in a row, most potential use of that row is likely messed up. One way CFA is found is by adding an offset to the value of a machine register for the range in question, Ln up to L(n+1) [or based on the end of the overall range for the last Ln]. I will use that for illustration because there are examples of this in my testing. /lib/libgcc_s.so.1 does not implement this fully for some DW_CFA_* operations: QUOTE (note the "every register" reference, so including CFA) DW_CFA_remember_state The DW_CFA_remember_state instruction takes no operands. The required = action is to push the set of rules for every register onto an implicit = stack. DW_CFA_restore_state The DW_CFA_restore_state instruction takes no operands. The required = action is to pop the set of rules off the implicit stack and place them = in the current row. END QUOTE In other words: push and pop a complete row, not just machine registers information from the row. For example, the the "cfa_offset" for computing the CFA value from from a register is not saved and restored. Nor is which register the offset is based on. (This can vary, though not in my examples.) In general the CFA cell is not saved and restored, what ever its contents. So any compiler that produces code depending on DW_CFA_remember_state and DW_CFA_restore_state for .eh_frame like material ends up with C++ exception handling messed up when the DW_CFA_restore_state should change the CFA to a=20 non-default one (from the prior DW_CFA_remember_state). This prevents reliable use of throwing C++ exceptions when building via the likes of devel/powerpc64-gcc or lang/gcc8 ( when not using -Wl,-rpath=3D-Wl,-rpath=3D/usr/local/lib/gcc8 so that /lib/libgcc_s.so.1 ends up being used). One result can be _Unwind_RaiseException looping looking at the same frame over and over instead of progressing to the next frame. For example, this happens via cfa_offset 0 being used. devel/powerpc64-gcc -O2 code tends to get that. Notes: For powerpc64, clang++ tends to use another register (%r31) with the old value (of %r1, the stack pointer) instead of involving the DW_CFA_remember_state/DW_CFA_restore_state pair based on just %r1. (clang has other problems relative to sue for buildworld buildkernel.) Code generation styles matter for if the incomplete coverage by /lib/libgcc_s.so will be visible or not. At this stage, WITH_LLVM_LIBUNWIND=3D builds targeting powerpc64 do not even compile/assemble the relevant code, apparently both because of darwin specific assembler code and FreeBSD's build not using the C-preprocessor on the .S file as required. (There could be more to getting it working.) I do not know about other architecture/compiler (or toolchain) combinations that may not yet be able to use WITH_LLVM_LIBUNWIND=3D . But I'd expect a potentially similar status from some. A range of modern /usr/local/lib/gcc*/libgcc_s.so do implement DW_CFA_remember_state/DW_CFA_restore_state operations and they are put to use. So using the likes of -Wl,-rpath=3D/usr/local/lib/gcc8 works for g++8 C++ exception handling (but is problematical for buildworld buildkernel). I made a similar exploration of the issue in around early 2016 and got basically the same results, not that I remembered much. But I now have a small source code example that shows the cfa_offset issue for the likes of devel/powerpc64-gcc output. The standard source for throw_exception in /lib/libgcc_s.so produces the cfa_offset problem when devel/powerpc64-gcc is used to buildworld. This turns all thrown C++ exceptions in to unbounded looping in _Unwind_RaiseException for that kind of context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Thu Oct 18 23:43:54 2018 Return-Path: Delivered-To: freebsd-toolchain@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 3790AF78C80 for ; Thu, 18 Oct 2018 23:43:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-4.consmr.mail.bf2.yahoo.com (sonic306-4.consmr.mail.bf2.yahoo.com [74.6.132.43]) (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 688B48408E for ; Thu, 18 Oct 2018 23:43:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: q1ZaTX8VM1l3kULXorahx9331cWS_TDGqXFHpdZe4jdHODYK1JGvK3PdZn7BQM7 yzqe323UC4mpXFXu1VsfRMvY5piF50xHWqGuV_4vOlrZYB2wJezl4nhsroZhsxgltp9JQY0wa4FL 1aLHI_Lf8ltoqamWWyvXksw7.dx8NR4jmG1Sb0w5iXNjJNPXbaK2IPSfPDFkpzDpzR_0wv1ZnoYS MXwIrvbGUbYEGMdz.cpO6eTiXLJ_lG3KLOjpFzpGlp0hpz_xgzf7y85fE2iqqvNTPOYLvyblJpgp 599EbgmL5oGvA3vwf7I1vbrLE1ST9yHx1pFp1WSUu5gARHMmKVG7Dm6.3X4vs4FS1J2MgwIOA7Ql G7XuSppDbT2Kv.NZvkO1zHmtAbezz0syLm5nSHq8YswDfQpRfqsL7rCVnE0Z0RNgi8nUn1JW_FIM kMJFvhUAFDnBlTTGnNcn85yrVnom5URogg_5mxsEhNDlXpeE0Jmjk8DsDx8h7dUe5XQE5vdG12uX IZ1rnDYCDWT7ybthDG1abIQNPaAaprSnUDcSwQTHfChNCuD85jocqgrMjqMszJW.QL5ZMmVET3sl pM._9xn0A_w8BZLrUGWqqlXthuO8gWC4wliouHZuzHqC2K7ze1nwdotbyVrboA4yOHsRKjwzjb5s hDvDB3boJV9KIu1MdoXreB2FDVpJqE0n2O.amHXr81t63_d7V5eqFhTxf4DLY6a2wweIH6F0U6mp HU6BCM5oL3c7Y4ywH7UQ9OfPSKK1S_kuujsmhSQEmskSa7HqQ4EhejftIvralY0jMxRy05XeshBY uRIvI566oikq3RNLAH0f5y6.THssVTQFBa3hyvUUj62hPD2ZwqSzkXJUJiA3_aDvgLRWa9q.8nbu 3FywMvqn4SSCgsuEtJE.1EuK4cfNaZAV8YVapjiLquvSOtIZ3VpUvhHGvHaZU.gVm0R64dHaru6o Az6RWfDrOn8f6BWr2JNHac_OqORB6GY0N3QCoAkpu20_6d85QZrAimCuucqhFEnaUeYBJfDtn2tZ 3wQwowzR6be55c340PDPsTYCgAP_j0cWGVEoXkitfEHFDnVWTvWAwf3vR_9n0X9UNsz0vAC0ARlX 3sweLJLo4pDx_qzVqHA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 18 Oct 2018 23:43:46 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a646330be3e13d20eaceb7b17daac9d4; Thu, 18 Oct 2018 23:43:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: What is incomplete for /lib/libgcc_s.so-based C++ exception handling (where WITH_LLVM_LIBUNWIND= and /usr/local/lib/gcc*/libgcc_s.so are not used) From: Mark Millard In-Reply-To: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> Date: Thu, 18 Oct 2018 16:43:40 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> To: FreeBSD Toolchain , FreeBSD , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 23:43:54 -0000 [I add a note indicating that clang++ does generate examples of DW_CFA_remember_state and DW_CFA_restore_state use for pwoerpc64 that lead to /lib/libgcc_s.so messing up the exception handling.] On 2018-Oct-17, at 1:25 PM, Mark Millard wrote: > [This summarizes other results without the code > and debugger evidence and such from my recent > explorations. It should be much easier to > follow than my exploration reports.] >=20 > Documents like DWARF5.pdf document the "row" vs. Location > information for Call Frame Information as (also used > for .eh_frame like materials for C++ exception handling): > (CFA: Cannonical Frame Address) >=20 > QUOTE ("Structure of Call Frame Information") > LOC CFA R0 R1...RN >=20 > L0 >=20 > L1 >=20 > ... >=20 > LN > END QUOTE >=20 > Note that the CFA is conceptually one of the > registers in each row, even though it is not a > machine register but a way to calculate the > conceptual register's value from machine > registers. >=20 > The information for the machine registers are > typically based on the earlier CFA value (from > the same row!). Absent a correct CFA cell in > a row, most potential use of that row is likely > messed up. >=20 > One way CFA is found is by adding an offset to > the value of a machine register for the range > in question, Ln up to L(n+1) [or based on the > end of the overall range for the last Ln]. I > will use that for illustration because there > are examples of this in my testing. >=20 > /lib/libgcc_s.so.1 does not implement this > fully for some DW_CFA_* operations: >=20 > QUOTE (note the "every register" reference, so including CFA) > DW_CFA_remember_state >=20 > The DW_CFA_remember_state instruction takes no operands. The required = action is to push the set of rules for every register onto an implicit = stack. >=20 > DW_CFA_restore_state >=20 > The DW_CFA_restore_state instruction takes no operands. The required = action is to pop the set of rules off the implicit stack and place them = in the current row. > END QUOTE >=20 > In other words: push and pop a complete row, > not just machine registers information from > the row. >=20 > For example, the the "cfa_offset" for computing the CFA > value from from a register is not saved and restored. > Nor is which register the offset is based on. (This > can vary, though not in my examples.) In general the > CFA cell is not saved and restored, what ever its > contents. >=20 > So any compiler that produces code depending on > DW_CFA_remember_state and DW_CFA_restore_state > for .eh_frame like material ends up with C++ > exception handling messed up when the > DW_CFA_restore_state should change the CFA to a=20 > non-default one (from the prior > DW_CFA_remember_state). >=20 > This prevents reliable use of throwing C++ exceptions > when building via the likes of devel/powerpc64-gcc > or lang/gcc8 ( when not using > -Wl,-rpath=3D-Wl,-rpath=3D/usr/local/lib/gcc8 so that > /lib/libgcc_s.so.1 ends up being used). One result > can be _Unwind_RaiseException looping looking at > the same frame over and over instead of progressing > to the next frame. For example, this happens via > cfa_offset 0 being used. devel/powerpc64-gcc -O2 > code tends to get that. >=20 >=20 > Notes: >=20 > For powerpc64, clang++ tends to use another register > (%r31) with the old value (of %r1, the stack pointer) > instead of involving the > DW_CFA_remember_state/DW_CFA_restore_state pair > based on just %r1. (clang has other problems > relative to sue for buildworld buildkernel.) /usr/tests/lib/atf/libatf-c++/detail/exceptions_test has examples were clang++ generated use of DW_CFA_remember_state and DW_CFA_restore_state and /lib/libgcc_s.so 's _Unwind_RaiseException ends up stuck looping. There are other examples as well. The problem is not limited to devel/powerpc64-gcc or other g++ use that uses /lib/libgcc_s.so . > Code generation styles matter for if the incomplete > coverage by /lib/libgcc_s.so will be visible or not. >=20 > At this stage, WITH_LLVM_LIBUNWIND=3D builds > targeting powerpc64 do not even compile/assemble > the relevant code, apparently both because of > darwin specific assembler code and FreeBSD's build > not using the C-preprocessor on the .S file as > required. (There could be more to getting it > working.) >=20 > I do not know about other architecture/compiler > (or toolchain) combinations that may not yet be > able to use WITH_LLVM_LIBUNWIND=3D . But I'd > expect a potentially similar status from some. >=20 > A range of modern /usr/local/lib/gcc*/libgcc_s.so > do implement DW_CFA_remember_state/DW_CFA_restore_state > operations and they are put to use. So using the likes > of -Wl,-rpath=3D/usr/local/lib/gcc8 works for g++8 C++ > exception handling (but is problematical for buildworld > buildkernel). >=20 > I made a similar exploration of the issue in around > early 2016 and got basically the same results, not that > I remembered much. But I now have a small source code > example that shows the cfa_offset issue for the likes > of devel/powerpc64-gcc output. >=20 > The standard source for throw_exception in > /lib/libgcc_s.so produces the cfa_offset problem > when devel/powerpc64-gcc is used to buildworld. > This turns all thrown C++ exceptions in to > unbounded looping in _Unwind_RaiseException for > that kind of context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Fri Oct 19 14:24:08 2018 Return-Path: Delivered-To: freebsd-toolchain@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 AB0E6FCC588 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 302E97FB68 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-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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)