From owner-freebsd-arch@freebsd.org Wed Oct 17 20:25:50 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 03EDD10DE807 for ; Wed, 17 Oct 2018 20:25:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.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 093AC905D6 for ; Wed, 17 Oct 2018 20:25:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .17zpVUVM1mNnfw6qZnnlw061.Segc8FdcVUgNsvTmB9z6anzaXPsRxzu.xUlWG XoykGuRCrwNL0IpO90jz27_P3TFPN9lLo7HRFoBWQVpXmz7Yd6WfYkXvtjCexuDIzNKyUW0ucnkO OBAnbi4xXmqsDGTcLVfe4lc7CW90AyQPvGnVrxJGSVCQxTSBKX2j7723LSPb5dBOcF0bi7vHs7x2 dD6KRV.mrt8tR.m6ki7PMkCWqzyOUIt_wXUUslaUcpE5aGbIJS92M.CXPybvCePGE0646iFSu_ka giF0dGnTpUD5fw6Hi.6i1kP4rPBx7ZJeRxLpS4cBgdNW3iciKzzDmapspgPWsP0CHn.9jqVN9JKB 64Vv3xWglFOOvTnYEQUgnV_LGHm9SFFWBCEGjI.1Vqjl5tYnzDq816F0FngxTJqbK_Bx9eOHha1e 2tdJ_PIJNj6V3pxEsDQZ12D8E2HDuF7Ix2E8RkTMPHDVOB2R9rMQXWRaw9jxJECUUAuc7Ul27iYG plKsEYS2L_bLTdVORUnPFDqUfx6XHJ9aXvLW2uJRe76pc6MKxevZnIxACvEiB9tQBQIKsZFQswJo 3bRnmyvPRzzyVwP0he80jLvT4MXIe6Fsg2GTyO4fiYolX07fig1KnIZYq27HhbxlJC_P4k1._FlZ L0HtMQTHGGr9ggWvww7w7mYe0ecyEGxq4Q8moct1WsQWhrOf4rxGCLIfZWnu75P5MGvLVAvkVNCO DpSa01D8nx44xnRoMQA1gpMuW5G2_OUbLLRLeKUfKyEeysslm4fSmF__JtdzYKXN9QnJ6YWfgB1C 9Ea1mApJvKPxEqbViksKSxu7ZzTSUlOXBX4sXkgzBIVEGshktXq2v644DcxnIUzfdDGLia6WS_zw aZhT9rj8cjy48hIFaa7YlSjRQWLT938oSOcdFNuRkv2KgHIudc1o5mXC4Q6Eh.sp6nNxWIzboF2x CLPkdN8PcPbSfJpl.GfEXSE4Sz3IhNfLGXLQzk6UG9AMiopmJFbsZsDW7oHJSaRwtPZT.uKAjfBy jgtyAU_d4.ohptH4OsDwIYIdQbRjLTU9gEoGmIIucszgdt0YlN6oYYz6en_sMqVzPbMeowXQX9iV LMhA3zBqH9RSen_4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Oct 2018 20:25:42 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 80e922adb91863636bdf56988756cc64; Wed, 17 Oct 2018 20:25:40 +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: 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) Message-Id: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> Date: Wed, 17 Oct 2018 13:25:39 -0700 Cc: FreeBSD PowerPC ML 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.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 20:25:50 -0000 [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.] 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) QUOTE ("Structure of Call Frame Information") LOC CFA R0 R1...RN L0 L1 ... LN END QUOTE 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. 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. 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. /lib/libgcc_s.so.1 does not implement this fully for some DW_CFA_* operations: QUOTE (note the "every register" reference, so including CFA) DW_CFA_remember_state 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. DW_CFA_restore_state 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 In other words: push and pop a complete row, not just machine registers information from the row. 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. 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). 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. Notes: 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.) Code generation styles matter for if the incomplete coverage by /lib/libgcc_s.so will be visible or not. 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.) 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. 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). 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. 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)