From owner-freebsd-ppc@freebsd.org Tue Nov 29 22:47:02 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D8A5C5C669 for ; Tue, 29 Nov 2016 22:47:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02A7F19EA for ; Tue, 29 Nov 2016 22:47:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17977 invoked from network); 29 Nov 2016 21:46:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Nov 2016 21:46:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Tue, 29 Nov 2016 16:47:08 -0500 (EST) Received: (qmail 10000 invoked from network); 29 Nov 2016 21:47:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Nov 2016 21:47:07 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 64CCCEC8F93; Tue, 29 Nov 2016 13:47:00 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? Message-Id: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> Date: Tue, 29 Nov 2016 13:46:59 -0800 Cc: Dimitry Andric To: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 22:47:02 -0000 I experiment with finding issues with using clang as the FreeBSD system compiler for TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 . I = report what I find, including to llvm's bugzilla. The following questions are driven by that but likely apply to other contexts. Summary: Does using clang 3.9.0 as the system compiler imply one should = or must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work? Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria for what dwarfdump should show for the exception information (if the information to be shown is to be correct/sufficient for libunwind)? Your answer's detail might indicate that I've misdirected the llvm folks in submittals like https://llvm.org/bugs/show_bug.cgi?id=3D26844 . There is also the question of if/when llvm's libunwind is ready to be = used for powerpc64 or powerpc (or . . .) if there are architecture specifics involved. That answer might determine when C++ exceptions work (and so when devel/kyua might have a chance to work) and is sort of separate = from the main question here but is still of interest overall. Should powerpc64 and powerpc clang 3.9.0 testing be using WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? https://llvm.org/bugs/show_bug.cgi?id=3D26844 has some of my notes about clang's output not matching what is now the WITHOUT_LLVM_LIBUNWIND context. My notes have been extended to head -r309179's clang 3.9.0 for powerpc64. Even: #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } on powerpc64 when compiled by clang 3.9.0 from a TARGET_ARCH=3Dpowerpc64 buildworld that was built by clang 3.9.0 (an implicitly WITHOUT_LLVM_LIBUNWIND ) crashes with: Program terminated with signal SIGABRT, Aborted. #0 0x00000000502f8868 in .__sys_thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x00000000502f8868 in .__sys_thr_kill () from /lib/libc.so.7 #1 0x00000000502f8818 in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 #2 0x00000000502f8748 in abort () at = /usr/src/lib/libc/stdlib/abort.c:65 #3 0x00000000501c9cbc in _Unwind_GetGR (context=3D, = index=3D65) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:180 #4 uw_update_context_1 (context=3D, fs=3D) at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1353 #5 0x00000000501c78b0 in uw_init_context_1 (context=3D0xffffffffffffd1e0,= outer_cfa=3D0xffffffffffffd940, outer_ra=3D0x50179ea0 = <__cxa_throw(void*, std::type_info*, void (*)(void*))+248>) at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1442 #6 0x00000000501c7418 in _Unwind_RaiseException (exc=3D) = at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:92 #7 0x0000000050179ea0 in throw_exception (ex=3D) at = /usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:774 #8 __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at = /usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:801 #9 0x0000000010000cf0 in .main () (gdb) up 3 =20 #3 0x00000000501c9cbc in _Unwind_GetGR (context=3D, = index=3D65) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:180 180 gcc_assert (size =3D=3D sizeof(_Unwind_Word)); (gdb) list 175 /* This will segfault if the register hasn't been saved. */ 176 if (size =3D=3D sizeof(_Unwind_Ptr)) 177 return * (_Unwind_Ptr *) ptr; 178 else 179 { 180 gcc_assert (size =3D=3D sizeof(_Unwind_Word)); 181 return * (_Unwind_Word *) ptr; 182 } 183 } (Absent the assert it might have gotten SIGSEGV.) My notes to llvm have dwarfdump output and words about what it shows relative to what gcc shows for the likes of _Unwind_RaiseException . I also show what Unbuntu Mate 16.10 has. But are the comparisons I made appropriate since they are based implicitly on WITHOUT_LLVM_LIBUNWIND ? Note: Now that the code generation has the registers and stack handling for powerpc64 in the area no longer stomping on or mis assigning the pointers to stack frames the exceptions oddities are easier to look at: gdb can actually report correctly for bt. I'll need to be explicit about WITHOUT_LLVM_LIBUNWIND vs. WITH_LLVM_LIBUNWIND on llvm's bugzilla in the future. =3D=3D=3D Mark Millard markmi at dsl-only.net