From owner-freebsd-arch@freebsd.org Thu Oct 18 23:43:53 2018 Return-Path: Delivered-To: freebsd-arch@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 C806BF78C7C for ; Thu, 18 Oct 2018 23:43:53 +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 642988408D 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-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture 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)