From owner-freebsd-toolchain@freebsd.org Thu Dec 1 02:03:40 2016 Return-Path: Delivered-To: freebsd-toolchain@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 C8DE4C5E35C for ; Thu, 1 Dec 2016 02:03:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-60.reflexion.net [208.70.210.60]) (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 8DD7411E3 for ; Thu, 1 Dec 2016 02:03:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21460 invoked from network); 1 Dec 2016 02:03:20 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Dec 2016 02:03:20 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Wed, 30 Nov 2016 21:03:18 -0500 (EST) Received: (qmail 16671 invoked from network); 1 Dec 2016 02:03:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Dec 2016 02:03:18 -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 AD039EC9006; Wed, 30 Nov 2016 18:03:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: 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? From: Mark Millard In-Reply-To: Date: Wed, 30 Nov 2016 18:03:32 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Dimitry Andric Content-Transfer-Encoding: 7bit Message-Id: <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Dec 2016 02:03:40 -0000 On 2016-Nov-29, at 2:56 PM, Ed Maste wrote: > On 29 November 2016 at 16:46, Mark Millard wrote: >> >> >> 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)? > > It does not. It should be possible to build a functional system both > WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the > _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind > data. Good to know. Thanks. [As there are no clang-based powerpc64 linux builds to my knowledge the following uses amd64/x86_64 examples instead for comparisons.] What I see from "dwarfdump -v -v -F .../libgcc_s.so.1" for FreeBSD head -r309179 vs. what I see for the clang 3.8.0 based OpenMandriva Lx V3.0 leaves me a little worried: OpenMandriva Lx V3.0 is more like what I would expect for: _Unwind_RaiseException (9990 vs. c701) _Unwind_ForcedUnwind (a330 vs. c857) _Unwind_Resume (9fb0 vs. c927) _Unwind_Resume_or_Rethrow (2da0 vs. c9e4) (The numbers are just for my reference in finding the dwarfdump material.) By contrast FreeBSD has missing information from what I can tell. For these 4 routines only: OpenMandriva Lx has scratch registers listed (r0 and r1 from the set of normally volatile registers normally not listed). No other routines in libgcc_s.so.1 have this. FreeBSD has no such extra registers listed anywhere, including not on the 4 where I'd expect them. Using _Unwind_RaiseException as an example of those 4 routines that I'm worried about. . . [Notes: r7 is %rsp, r6 is %rbp, r3 is %rbx, r2 is %rcx, r1 is %rdx, and r0 is %rax in amd64/x86_64 land. Only OpenMandriva Lx had examples of the last two. I use the dwarfdump naming below.] FreeBSD _Unwind_RaiseException: fde section offset 5328 0x000014d0 cie offset for fde: 5332 0x000014d4 0 DW_CFA_advance_loc 1 (1 * 1) 1 DW_CFA_def_cfa_offset 16 3 DW_CFA_offset r6 -16 (2 * -8) 5 DW_CFA_advance_loc 3 (3 * 1) 6 DW_CFA_def_cfa_register r6 8 DW_CFA_advance_loc 16 (16 * 1) 9 DW_CFA_offset r3 -56 (7 * -8) 11 DW_CFA_offset r12 -48 (6 * -8) 13 DW_CFA_offset r13 -40 (5 * -8) 15 DW_CFA_offset r14 -32 (4 * -8) 17 DW_CFA_offset r15 -24 (3 * -8) 19 DW_CFA_nop 20 DW_CFA_nop 21 DW_CFA_nop 22 DW_CFA_nop All the registers referenced are very common: lots of routines having nothing to do with the Exception handling also list them. OpenMandriva Lx _Unwind_RaiseException: fde section offset 4280 0x000010b8 cie offset for fde: 4284 0x000010bc 0 DW_CFA_advance_loc 1 (1 * 1) 1 DW_CFA_def_cfa_offset 16 3 DW_CFA_offset r6 -16 (2 * -8) 5 DW_CFA_advance_loc 3 (3 * 1) 6 DW_CFA_def_cfa_register r6 8 DW_CFA_advance_loc 8 (8 * 1) 9 DW_CFA_offset r15 -24 (3 * -8) 11 DW_CFA_offset r14 -32 (4 * -8) 13 DW_CFA_offset r13 -40 (5 * -8) 15 DW_CFA_offset r12 -48 (6 * -8) 17 DW_CFA_advance_loc 20 (20 * 1) 18 DW_CFA_offset r3 -56 (7 * -8) 20 DW_CFA_offset r1 -64 (8 * -8) 22 DW_CFA_offset r0 -72 (9 * -8) 24 DW_CFA_advance_loc2 284 27 DW_CFA_remember_state 28 DW_CFA_restore r6 29 DW_CFA_def_cfa r2 8 32 DW_CFA_advance_loc 4 (4 * 1) 33 DW_CFA_restore_state 34 DW_CFA_advance_loc 21 (21 * 1) 35 DW_CFA_def_cfa r7 8 38 DW_CFA_nop Note the lines for r1 and r0 that FreeBSD has no equivalent of: These are the Exception ABI's scratch registers usage that only apply to exception handling code that uses certain built-ins that imply the context. In normal routines r1 and r0 are volatile and so are not listed on OpenMandriva Lx. But FreeBSD never lists any scratch registers for the exception handing ABI, unlike the Itanium's standard that specified there are 4 --2 with predefined purposes. (Itanimum used GP15-GP18 for the exception handling scratch registers or something like that if I remember right.) So the amd64 FreeBSD information from clang 3.9.0 looks wrong to me unless the Itanium's standard is not the basis for what FreeBSD is doing here. NOTE: Analogous incorrectness with observed scratch register usage in builds based on clang 3.8.0 and clang 3.9.0 for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 are part of what I've reported as wrong to llvm for what blocks clang for them. In this context actual crashes from asserts or SIGSEGV during _Unwind_GetGR or _Unwind_SetGR for a scratch register's index is what started my investigation of the dwarfdump reports in the first place. I found the register information missing in the dwarfdump output and comments in the code about being such a missing status for any GR leading to what I had observed for references to that GR --and that is my interpretation of the code so commented as well. > Eventually new features may show up in Clang and LLVM's libunwind (and > new versions of GNU's unwinder) that won't work with the old unwinder. > >> Your answer's detail might indicate that I've misdirected the llvm folks >> in submittals like https://llvm.org/bugs/show_bug.cgi?id=26844 . >> >> 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? > > For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My > eventual goal is to have a functioning Clang, LLD, LLDB, libunwind, > and ELF Tool Chain on all of our supported architectures. === Mark Millard markmi at dsl-only.net