From owner-freebsd-ppc@freebsd.org Sun Oct 14 07:40:34 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91EDB10C9152 for ; Sun, 14 Oct 2018 07:40:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.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 19CD37D737 for ; Sun, 14 Oct 2018 07:40:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: QSoO_Z4VM1nJy_Bs7OO3WE7VxJkvYHYJus4MXHY_JnzUBd8R6HpF56Nyqqfp8Lk 8r5E3dlwbIIC.J4Wo78c2xNx_NuThsALUopdrdZQArggSO9aQAC1mYCgx5Ar_Gnu9oLUhPrsfYLU WEfGyyrqc4vca0_oLnfozcQXbuC8d3XvzXfeOgiwm9KK20ktdrLsWuqRJYm.4gdXYPlFh3pN7QxA p2aFCfRXI63rTggXNqP8K5CgAY2iM9Ax2CeTrqDfFTWncmDlNR3VSC3cv33X_rhKFbxA.YQHW_Kn FVt5md81DGSo1Pv9nW6fzFyFAr2DFyyxceq8K_QHPa2zlN5XSuBsSQ0XmYVAmDv3olkY6LoLNDyN wgH1BKDOVIFQ2RBq0w4TTPtQQq.9Nax4beY8gPOaBP8eVa4lvGWiGLjcDhJ0SCP5yy_.1tH0bcHA 6OrjcRgbrI81aEJtMj6n_qDfb_fNrAgsHBHembqMTmK_Ov_sHTQxqnnqCzdNWhmfztiRbD_cVSki qdICkFLoYy0ZK796BYoFDiI5MdRx4ccHBLrFTR_2qQy6i01yFuYz1cJsNDtUlFakBFtKB0f0liyW HcHHQZ1oAFTvs6kdgXXFS5_D76CupV5ty_8gbend5lAPPl8N782k.gfCgoDiTTwoes6.Kgo96rWy PRcIsTIatUnJc0NABpL0xyIDcRnj97L5KowAvWzBYT1IvE1FOHHMVBbo6Ch6n7WUITCIM5JMJNAf iIDYiG8Hai7aFz08L64jixb64F6o2xgTankg_dkZXO5ETp2KQRMJvbbGVvPp8bTtaXVkLI03gIwx Zc9kAIopMqIn.0se4ajePj.EygruiPriYVQ3cPk08Qe1khEFSOIiJK6FxsaXxUxiPhHwyVZMtHM3 Mroqk39FCPZjxqXHEuIRHEdoafJKWTJkNenbvS8wUBXn9_FsDgv4Gs2_nO4Roh.2CyEB.5AyEYLb kGoWq0IUy94_8exQGTkwUFRSo_spbbshDm_kz31H2VmuPZ7Nlc52yomwGPXRHLP5zuuefvrTbyJz UkOkfKKTt3zbvHjMPYtV8cUbR5LPO4SB70FEVuJmDbVf92We07EDz2co5oECvmBnVsg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 Oct 2018 07:40:31 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c6881e5bb5193b8e3e3578a39f1f6be7 for ; Sun, 14 Oct 2018 07:40:28 +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: 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) Date: Sun, 14 Oct 2018 00:40:27 -0700 References: To: FreeBSD PowerPC ML In-Reply-To: Message-Id: <0539C16B-1603-4639-914A-0308578C7262@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 07:40:34 -0000 On 2018-Oct-12, at 1:59 PM, Mark Millard wrote: > 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 > Some time ago I'd used system-clang to build such > programs in an environment built via devel/powerpc64-gcc > and devel/powerpc64-binutils and the programs worked. > The same for devel/powerpc64-gcc use: the code it > produced for the programs also worked. At this point > I've no clue what changed or when. >=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 Here is what I've found so far. The code is looping in the following routine. (I've inserted 2 NOTE: lines for what the sustained looping is like.) _Unwind_Reason_Code _Unwind_RaiseException(struct _Unwind_Exception *exc) { struct _Unwind_Context this_context, cur_context; _Unwind_Reason_Code code; =20 /* Set up this_context to describe the current stack frame. */ uw_init_context (&this_context); cur_context =3D this_context; =20 /* Phase 1: Search. Unwind the stack, calling the personality routine with the _UA_SEARCH_PHASE flag set. Do not modify the stack yet. = */ while (1) { _Unwind_FrameState fs; =20 /* Set up fs to describe the FDE for the caller of cur_context. = The first time through the loop, that means __cxa_throw. */ code =3D uw_frame_state_for (&cur_context, &fs); NOTE: code =3D=3D _URC_NO_REASON always results if (code =3D=3D _URC_END_OF_STACK) /* Hit end of stack with no handler found. */ return _URC_END_OF_STACK; if (code !=3D _URC_NO_REASON) /* Some error encountered. Ususally the unwinder doesn't diagnose these and merely crashes. */ return _URC_FATAL_PHASE1_ERROR; /* Unwind successful. Run the personality routine, if any. */ if (fs.personality) NOTE: fs.personality never evaluates to true { code =3D (*fs.personality) (1, _UA_SEARCH_PHASE, = exc->exception_class, exc, &cur_context); if (code =3D=3D _URC_HANDLER_FOUND) break; else if (code !=3D _URC_CONTINUE_UNWIND) return _URC_FATAL_PHASE1_ERROR; } /* Update cur_context to describe the same frame as fs. */ uw_update_context (&cur_context, &fs); } /* Indicate to _Unwind_Resume and associated subroutines that this is not a forced unwind. Further, note where we found a handler. = */ exc->private_1 =3D 0; exc->private_2 =3D uw_identify_context (&cur_context); cur_context =3D this_context; code =3D _Unwind_RaiseException_Phase2 (exc, &cur_context); if (code !=3D _URC_INSTALL_CONTEXT) return code; uw_install_context (&this_context, &cur_context); } =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)