From owner-freebsd-ppc@freebsd.org Fri Dec 2 21:37:39 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 BB795C6387C for ; Fri, 2 Dec 2016 21:37:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (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 7E494634 for ; Fri, 2 Dec 2016 21:37:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17286 invoked from network); 2 Dec 2016 21:11:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Dec 2016 21:11:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 02 Dec 2016 16:11:05 -0500 (EST) Received: (qmail 416 invoked from network); 2 Dec 2016 21:11:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Dec 2016 21:11:05 -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 78DAAEC8B60; Fri, 2 Dec 2016 13:10:57 -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: Fri, 2 Dec 2016 13:10:56 -0800 Cc: FreeBSD Toolchain , Dimitry Andric , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1016640A-6065-47A6-BF8C-F9DC2A38127A@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> <8BA319C6-FAD1-445F-85C1-5086B5AA59A8@dsl-only.net> To: Ed Maste 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: Fri, 02 Dec 2016 21:37:39 -0000 On 2016-Dec-2, at 12:12 AM, Mark Millard wrote: > [Reminder of my context: these amd64 efforts are really > trying to make sure that I interpret powerpc family behavior > correctly for C++ exception handling. Still it may be that > there are other useful side-effects of my investigations.] >=20 > On 2016-Dec-1, at 8:57 PM, Mark Millard = wrote: >=20 >> Quick summaries from looking around at official amd64 builds >> (via downloaded .iso's installed in VirtualBox under Mac OS X): >>=20 >> _Unwind_RaiseException content (amd64 context only): >>=20 >> RaiseExc. RaiseExc. RaiseException >> dwarfdump save/rest. has "mov %rcx,%rsp" >> r0?,r1? rdx? rax? return path? >> --------- ---------- ------------------ >> release/9.3.0: r0,r1 rdx,rax mov %rcx,%rsp path >> release/10.3.0: r0,r1 rdx,rax mov %rcx,%rsp path >> stable/10 -r309258: r0,r1 rdx,rax mov %rcx,%rsp path >> release/11.0.1: r0,r1 rdx,rax mov %rcx,%rsp path >> stable/11 -r309280: r0,r1 rdx,rax mov %rcx,%rsp path >> head (12) -r309302: I have confirmed that head being different above for amd64 is because of the default WITH_LLVM_LIBUNWIND=3D and when built using WITHOUT_LLVM_LIBUNWIND=3D head is like the others for the above types of information. I've added a note to my llvm report (26844) for powerpc64 and powerpc indicating that all the specific material tied to dwarf .eh information that I reported is for use of WITHOUT_LLVM_LIBUNWIND=3D (for ppc and ppc64: the default for both FreeBSD 11 and currently for head [12]). I noted that comparing to WITH_LLVM_LIBUNWIND=3D dwarf information was more complicated: one needs to know the expected differences but I did not go into details. > The following notes are not about the above differences > in head vs. the others. I've not figured a good way to > investigate the implications of head (12)'s differences > above. >=20 >> My simple example program's content compiled under the >> host compiler: >> ("clang++ -g -std=3Dc++11 -pedantic -O2" when possible.) >>=20 >> program uses pre _cxa_begin_catch compare and = jump >> _Unwind_Resume? logic? >> --------------- = ------------------------------------------- >> release/9.3.0: _Unwind_Resume sub $0x1,%rdx; je to = _cxa_begin_catch call >> release/10.3.0: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch >> stable/10 -r309258: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch >> release/11.0.1: >> stable/11 -r309280: >> head (12) -r309302: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch These compiles have no clue if the eventual system was built using WITHOUT_LLVM_LIBUNWIND=3D vs. WITH_LLVM_LIBUNWIND=3D and so will persist independently. > I explored more simple programs and. . . >=20 > It looks like clang as it is in 11 treats: >=20 > catch (std::& e) { . . . } >=20 > as the last (or only) catch for a try as "catch > everything" even for -O0 in the machine code, > no separate _Unwind_Resume call for "no match". >=20 > 11 depends on the other .eh information and its > interpretation to avoid mis-delivery to the > clause sequence for such a try. >=20 > [The powerpc family may be similar. I need to > avoid misreporting such differences from the > general prior history to llvm as clang compiler > problems.] >=20 > [Back to amd64 land. . .] > The other versions/configurations of clang and the > g++ 4.2.1 compiler include the test and jump code > to skip catches in sequence (including the last one > in the try's source) and have use of _Unwind_Resume > when the sequence does not have a match. >=20 > So under 11.x older code's test and jump code might > be redundant but is still apparently correct. >=20 > It may be that such code is also redundant for head > (12). But it appears that 12's machine code would > then also have such redundant code as well. >=20 > If there is some case where such code is not > redundant for head (12) then 11's machine code > might have problems under head in such cases. > I do not know that any such case exists. >=20 >=20 > I separately remind of the %rdx (64 bit) vs.=20 > %edx (32-bit) use in the test and jump code, > 9.3.0 code being the odd code with %rdx in use > that involves more bits. >=20 >=20 > [Again: The above ignores the head (12) > differences in libgcc_s.so.1 .eh dwarf > information for _Unwind_RaiseException and > the like and the library's noted machine > code differences for _Unwind_RaiseException > as well.] =3D=3D=3D Mark Millard markmi at dsl-only.net