From owner-freebsd-ppc@freebsd.org Sun Mar 10 19:17:59 2019 Return-Path: Delivered-To: freebsd-ppc@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 15E0C153E353 for ; Sun, 10 Mar 2019 19:17:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (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 657D38A32C for ; Sun, 10 Mar 2019 19:17:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Bp4VcKsVM1m.NfTJqgPVtBoQs01Dpq1R0Ck8ChXSZjrqn0H0oWbxjYPkcvhxLRz kqhe2Hmr5TbD64egqw0S0KAddWfAWl5Q4DzfnlVuurRaZYVvxuT8_CzUS9E85v0LXLuTaPT7k7zP ePRtXfKF4T_2dsPZLvqZK0IiDYzHv8NpDrKY5LkhDxeEvAsJ0uYm9NoVh1e8NuYC5DRfYJ7j7Iz0 H37HoXxVpay0YqhKM6RkjxolV5h2PJmawPMmu5mz1sQqMiGJu8je_AI1kpvw1MkardKkm0aaaLWP 4oDEGS1dUNKUU6UNrH_Jlx0qNTYknN3XJD9ekDRnvbI5K.8yHRe0wON6lqW6kt0.a7h0TH12Xnv0 dhaQeXF_ZpiQuGyv20hKLVlVV1ERGLRUF5YaEyelAM6I6eMfqe13eB.lsj2n_JCVAqBhVLK03YSm VJyv3JcSIW1tSt.fp4hjIfZStd2Vxl.2BBXCCFARKzLVypPzDQ8B2kRF_MMeqXX1y4Kk5CztBjK5 xLb12j.qulVjdrOEqoFOCVsqk5Na1Hag4F13i9.SoZ1eX6TpNhHfQ1WTmFeAM_fAuah5OCfl3QL3 fVQYtpZ.RzQLkKXPojIgMN.TARm38fKK_pqagVZrDCC2SHxoooTx0hHEG5aY5exIlLNQ8DpLpxYu .Y3wh11.xNuv1_V54KDbuuoimlatVGHKTsgo3DWGvS9X.r0S5qAYnoUEjrZyTwmhABif0Xlk8BT. Pb3qpCWEBC_jnVHpVMHhRurZ5mUfd9TZ8N2s9LSejfWT21CZOEMlm.hjlejMHMWtfGI4XzooYtkw .nkn1qcouPN2ZxY6LVbKr6Gx7o8YlTy76xHJshR2QMnH3sevQI7HNzSF6adTY6WdY9DYecfWbgit OFMFB1wU6SVEHEMd0JZmSQv3h6FAe7fUtGFm_8pdb.IXJOUCeAKVDsqHb6hNZYIHDJ.VS4Uq0ihA mzwQx3wPOyZY5sWLe.a72bMRWGIaNl8w3wm9whyMjL5ozQrHC2JI2HbJ8D5ad.5edy2gKjWGp5Sd XHdQ7bJE1XeHJ9hjYcYkxaO8rf_Iro4zKmNbeLHaP4w1yg6PwxlZ4EYS0sF3LMi8bNJqMYPfSVA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Sun, 10 Mar 2019 19:17:49 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp422.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f687c20ca46223b1ea7a09a69a7dc82f; Sun, 10 Mar 2019 19:07:41 +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 12.2 \(3445.102.3\)) Subject: 32-bit powerpc: gcc8 unable to build devel/llvm80, for example: crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize@@FBSD_1.0' Message-Id: <1470043E-62EE-4F8C-A04F-4AFC003EC8CF@yahoo.com> Date: Sun, 10 Mar 2019 12:07:39 -0700 Cc: FreeBSD Toolchain To: ports-list freebsd , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 657D38A32C X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.27)[0.270,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.17)[ip: (-1.32), ipnet: 66.163.184.0/21(1.24), asn: 36646(0.99), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[205.186.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 19:17:59 -0000 My ports-mgmt/pouriere-devel based build attempt for building = devel/llvm80 failed with: [00:01:11] [01] [00:00:00] Building devel/llvm80 | llvm80-8.0.0.r3 [04:30:47] [01] [04:29:36] Saved devel/llvm80 | llvm80-8.0.0.r3 wrkdir = to: = /usr/local/poudriere/data/wrkdirs/FBSDpowerpc-default/default/llvm80-8.0.0= .r3.tbz [04:30:47] [01] [04:29:36] Finished devel/llvm80 | llvm80-8.0.0.r3: = Failed: build [04:31:10] [01] [04:29:59] Skipping devel/xtoolchain-llvm80 | = xtoolchain-llvm80-0.1: Dependent port devel/llvm80 | llvm80-8.0.0.r3 = failed [04:31:11] Stopping 2 builders The log shows: /usr/local/lib/gcc8/gcc/powerpc-portbld-freebsd13.0/8.3.0/crtbeginS.o: = in function `__do_global_dtors_aux': crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 = against symbol `__cxa_finalize@@FBSD_1.0' defined in .text section in = /lib/libc.so.7 tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `llvm::object_deleter<(anonymous = namespace)::RegisterFatalErrorHandler>::call(void*)': = CIndex.cpp:(.text._ZN4llvm14object_deleterIN12_GLOBAL__N_125RegisterFatalE= rrorHandlerEE4callEPv+0x0): relocation truncated to fit: R_PPC_PLTREL24 = against symbol `operator delete(void*)@@GLIBCXX_3.4' defined in .text = section in /usr/local/lib/gcc8/libstdc++.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `llvm::CrashRecoveryContextDeleteCleanup > >::recoverResources()': = CIndex.cpp:(.text._ZN4llvm33CrashRecoveryContextDeleteCleanupISt6vectorIPK= cSaIS3_EEE16recoverResourcesEv[_ZN4llvm33CrashRecoveryContextDeleteCleanup= ISt6vectorIPKcSaIS3_EEE16recoverResourcesEv]+0x28): relocation truncated = to fit: R_PPC_PLTREL24 against symbol `operator = delete(void*)@@GLIBCXX_3.4' defined in .text section in = /usr/local/lib/gcc8/libstdc++.so = CIndex.cpp:(.text._ZN4llvm33CrashRecoveryContextDeleteCleanupISt6vectorIPK= cSaIS3_EEE16recoverResourcesEv[_ZN4llvm33CrashRecoveryContextDeleteCleanup= ISt6vectorIPKcSaIS3_EEE16recoverResourcesEv]+0x40): relocation truncated = to fit: R_PPC_PLTREL24 against symbol `operator = delete(void*)@@GLIBCXX_3.4' defined in .text section in = /usr/local/lib/gcc8/libstdc++.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `std::_Sp_counted_ptr_inplace, = (__gnu_cxx::_Lock_policy)2>::~_Sp_counted_ptr_inplace()': = CIndex.cpp:(.text._ZNSt23_Sp_counted_ptr_inplaceIN5clang22PCHContainerOper= ationsESaIS1_ELN9__gnu_cxx12_Lock_policyE2EED0Ev[_ZNSt23_Sp_counted_ptr_in= placeIN5clang22PCHContainerOperationsESaIS1_ELN9__gnu_cxx12_Lock_policyE2E= ED5Ev]+0x0): relocation truncated to fit: R_PPC_PLTREL24 against symbol = `operator delete(void*)@@GLIBCXX_3.4' defined in .text section in = /usr/local/lib/gcc8/libstdc++.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `std::_Sp_counted_ptr_inplace, = (__gnu_cxx::_Lock_policy)2>::_M_destroy()': = CIndex.cpp:(.text._ZNSt23_Sp_counted_ptr_inplaceIN5clang22PCHContainerOper= ationsESaIS1_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv[_ZNSt23_Sp_coun= ted_ptr_inplaceIN5clang22PCHContainerOperationsESaIS1_ELN9__gnu_cxx12_Lock= _policyE2EE10_M_destroyEv]+0x0): relocation truncated to fit: = R_PPC_PLTREL24 against symbol `operator delete(void*)@@GLIBCXX_3.4' = defined in .text section in /usr/local/lib/gcc8/libstdc++.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `llvm::object_creator<(anonymous = namespace)::RegisterFatalErrorHandler>::call()': = CIndex.cpp:(.text._ZN4llvm14object_creatorIN12_GLOBAL__N_125RegisterFatalE= rrorHandlerEE4callEv+0x2c): relocation truncated to fit: R_PPC_PLTREL24 = against symbol `operator new(unsigned int)@@GLIBCXX_3.4' defined in = .text section in /usr/local/lib/gcc8/libstdc++.so = CIndex.cpp:(.text._ZN4llvm14object_creatorIN12_GLOBAL__N_125RegisterFatalE= rrorHandlerEE4callEv+0x3c): relocation truncated to fit: R_PPC_PLTREL24 = against symbol `llvm::install_fatal_error_handler(void (*)(void*, = std::__cxx11::basic_string, = std::allocator > const&, bool), void*)@@LLVM_8' defined in .text = section in lib/libLLVM-8.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `fatal_error_handler(void*, std::__cxx11::basic_string, std::allocator > const&, bool)': = CIndex.cpp:(.text._ZL19fatal_error_handlerPvRKNSt7__cxx1112basic_stringIcS= t11char_traitsIcESaIcEEEb+0x38): relocation truncated to fit: = R_PPC_PLTREL24 against symbol `fprintf@@FBSD_1.0' defined in .text = section in /lib/libc.so.7 = CIndex.cpp:(.text._ZL19fatal_error_handlerPvRKNSt7__cxx1112basic_stringIcS= t11char_traitsIcESaIcEEEb+0x3c): relocation truncated to fit: = R_PPC_PLTREL24 against symbol `abort@@FBSD_1.0' defined in .text section = in /lib/libc.so.7 tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `std::_Sp_counted_ptr_inplace, = (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)': = CIndex.cpp:(.text._ZNSt23_Sp_counted_ptr_inplaceIN5clang22PCHContainerOper= ationsESaIS1_ELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_inf= o[_ZNSt23_Sp_counted_ptr_inplaceIN5clang22PCHContainerOperationsESaIS1_ELN= 9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info]+0x5c): = additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/devel/llvm80 =3D>> Cleaning up wrkdir Context: # uname -apKU FreeBSD FBSDG4S 13.0-CURRENT FreeBSD 13.0-CURRENT #14 r344955M: Fri Mar = 8 22:39:44 PST 2019 = markmi@FBSDFSSD:/usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/= powerpc.powerpc/sys/GENERICvtsc-NODBG powerpc powerpc 1300014 1300014 (The 32-bit powerpc is running a gcc 4.2.1 based system. amd64 = system-clang built the bootstrap gcc 4.2.1 toolchain, which in turn built the system. The = 32-bit FreeBSD was running on a PowerMac G5 [2-sockets, 2 cores each].) # svnlite info /usr/ports/ | grep 'Re[plv]' Relative URL: ^/head Repository Root: svn://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 495006 Last Changed Rev: 495006 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Mon Mar 11 00:10:42 2019 Return-Path: Delivered-To: freebsd-ppc@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 8002F1523A0C for ; Mon, 11 Mar 2019 00:10:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 DBD986E3DF for ; Mon, 11 Mar 2019 00:10:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: KDNOktcVM1lqUJXzV4tIoPy.JpwdndXT1RnccL6V4HXU9e_wiWGMM74A0q0kM7d tZaFsDCXOWaW5P9TQ5aU_KWy3MM7CazC_aWUbNH7xb5k23hLQl_r485ctoe6xOKL8GztGic_Ia1d jgOXK4nIrFItX5zrGwYeQ66w134Qni8FxDDnrXVrlWycN2XJ5MKFJd0uzmBifxaS1H5jv5VhUcYC v3cFbK3ZnVxxTyEKUKvnlBhG.J5iiCk1OBlIiqHrx.aBi3BfaiOh.ns.mjpd96M9Z6gLpz5jBlSn SpzD8ELi2jFau0tHNLhNaIVsZbrYA94zQJGI0Qria2pV6San_4Ds44.L0Tndz3L2V9sLUdrYx70Y zwCpWT18oSmkOqXdRsRNfGe_e6jYj6rrnR5ON8NCDLrl11CnArNh1Tf47hhmp6sxLRNxB1hh41le jJeom.2jFZTV8EH4sOG1OZv3cqY57Rg8ZYdOG0xtXx.ttjQGhrUcrgM7yDOLEZQVj_l5e3NWBXJt HMNduajfqx3u.vAD.qb5MtOs9joKh7rwV9NPHqRHvqPBmTH9Hj9heEvcccR1.y_9BrlbF7.yhGHk qK.T2qn3jSy0nM01CzS5SIe73lHorLBfuM11drKAKzpuV0x9P30FxG7m1fi_fAkYosOlYbX1qZ2V UXjF9FXLo3v0ATS1TDB30q3NUEqXzuGobdS6TUrnbHBitB0k6IotL4YGcn5jHNjEZShlTjvb5XPn VBnGI5OicbbZOA6qxR3Podyj3oY21ka0jTPb7x5FiMT.eNSA7GcvOfe3G1bELHTQJhCmVYqmXb5y Z7XjjCaRVLr_7G5WtaTHucu_hnOCPd.IrvJ.Kto9DRTLlKcdSTi_vZXtXwRF1fI_VxNe0bmSdjPE YDG0upR17HrXjfLzVtzLIq6ph6A5Z_ZBJUPgjQk_qE7PEYcQGeBwrybLulf.Kb34mIUDjTo32aw7 PE7lpxs.suwNBnJ9onefCXKoyBxymh6HKrbSbEoLGGikTnvzX8ifKAt3Os2pFlG43hBFRy8h2vro DEA1vBk9DoCvHfnVwK8EVaH8w4CG4jPV669M5SiLgNUQTyCLritikWupoDT_sJvv7tW0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 11 Mar 2019 00:10:34 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp421.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1cd5e553d20e916b82dafe8c926bde74; Mon, 11 Mar 2019 00:10:30 +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 12.2 \(3445.102.3\)) Subject: 32-bit powerpc: gcc8 unable to build devel/llvm60: "/usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935" Message-Id: <1A031A56-9D18-4B12-B98B-302F94C5CF56@yahoo.com> Date: Sun, 10 Mar 2019 17:10:28 -0700 To: FreeBSD PowerPC ML , FreeBSD Toolchain , ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: DBD986E3DF X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.56 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.99)[0.993,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.52)[ip: (5.11), ipnet: 74.6.128.0/21(1.43), asn: 26101(1.15), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.94)[0.941,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.62)[0.616,0]; RCVD_IN_DNSWL_NONE(0.00)[42.135.6.74.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 00:10:42 -0000 My ports-mgmt/pouriere-devel based build attempt for building = devel/llvm60 failed with: [00:00:53] [01] [00:00:00] Building devel/llvm60 | llvm60-6.0.1_6 [02:05:13] [01] [02:04:20] Saved devel/llvm60 | llvm60-6.0.1_6 wrkdir = to: = /usr/local/poudriere/data/wrkdirs/FBSDpowerpc-default/default/llvm60-6.0.1= _6.tbz [02:05:14] [01] [02:04:21] Finished devel/llvm60 | llvm60-6.0.1_6: = Failed: build [02:05:30] Stopping 1 builders The log shows: [3365/4552] : && /usr/local/bin/g++8 -fPIC -O2 -pipe -DNDEBUG = -Wl,-rpath=3D/usr/local/lib/gcc8 -DNDEBUG -D_GLIBCXX_USE_C99 = -Wl,-rpath=3D/usr/local/lib/gcc8 -isystem /usr/local/include -fPIC = -fvisibility -inlines-hidden -Werror=3Ddate-time -std=3Dc++11 -Wall -W = -Wno-unused-parameter -Wwrite-strings -Wcast-qual = -Wno-missing-field-initializers -pedantic -Wno-long-long = -Wno-maybe-uninitialized -Wdelete-non-v irtual-dtor -Wno-comment -ffunction-sections -fdata-sections -O2 -pipe = -DNDEBUG -Wl,-rpath=3D/usr/local/lib/gcc8 -DNDEBUG -D_GLIBCXX_USE_C99 = -Wl,-rpath=3D/usr/local/lib/gcc8 -isystem /usr/local/include=20 -Wl,-rpath=3D/usr/local/lib/gcc8 -L/usr/local/lib/gcc8 -Wl,-z,origin = -Wl,-O3 -Wl,--gc-sections = -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto= /LTO.exports -shared -Wl,-so name,libLTO.so.6 -o lib/libLTO.so.6.0.1 = tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o = tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib = -Wl,-rpath,"\$ORIGIN/../lib:/usr/local/lib" lib/libLL VM-6.0.so && : FAILED: lib/libLTO.so.6.0.1=20 : && /usr/local/bin/g++8 -fPIC -O2 -pipe -DNDEBUG = -Wl,-rpath=3D/usr/local/lib/gcc8 -DNDEBUG -D_GLIBCXX_USE_C99 = -Wl,-rpath=3D/usr/local/lib/gcc8 -isystem /usr/local/include -fPIC = -fvisibility-inlines-hid den -Werror=3Ddate-time -std=3Dc++11 -Wall -W -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic = -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor=20 -Wno-comment -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG = -Wl,-rpath=3D/usr/local/lib/gcc8 -DNDEBUG -D_GLIBCXX_USE_C99 = -Wl,-rpath=3D/usr/local/lib/gcc8 -isystem /usr/local/include = -Wl,-rpath=3D /usr/local/lib/gcc8 -L/usr/local/lib/gcc8 -Wl,-z,origin -Wl,-O3 = -Wl,--gc-sections = -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto= /LTO.exports -shared -Wl,-soname,libLTO. so.6 -o lib/libLTO.so.6.0.1 = tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o = tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib = -Wl,-rpath,"\$ORIGIN/../lib:/usr/local/lib" lib/libLLVM-6.0.so && : /usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935 /usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935 collect2: error: ld returned 1 exit status . . . The assert seems to be the last BFD_ASSERT shown below: /* If this is a weak defined symbol in a dynamic object, and we know the real definition in the dynamic object, copy interesting flags over to the real definition. */ if (h->is_weakalias) { struct elf_link_hash_entry *def =3D weakdef (h); =20 /* If the real definition is defined by a regular object file, don't do anything special. See the longer description in _bfd_elf_adjust_dynamic_symbol, below. */ if (def->def_regular) { h =3D def; while ((h =3D h->u.alias) !=3D def) h->is_weakalias =3D 0; } else { while (h->root.type =3D=3D bfd_link_hash_indirect) h =3D (struct elf_link_hash_entry *) h->root.u.i.link; BFD_ASSERT (h->root.type =3D=3D bfd_link_hash_defined || h->root.type =3D=3D bfd_link_hash_defweak); BFD_ASSERT (def->def_dynamic); BFD_ASSERT (def->root.type =3D=3D bfd_link_hash_defined); (*bed->elf_backend_copy_indirect_symbol) (eif->info, def, h); } . . . Context: # uname -apKU FreeBSD FBSDG4S 13.0-CURRENT FreeBSD 13.0-CURRENT #14 r344955M: Fri Mar = 8 22:39:44 PST 2019 = markmi@FBSDFSSD:/usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/= powerpc.powerpc/sys/GENERICvtsc-NODBG powerpc powerpc 1300014 1300014 (The 32-bit powerpc is running a gcc 4.2.1 based system. amd64 = system-clang built the bootstrap gcc 4.2.1 toolchain, which in turn built the system. The = 32-bit FreeBSD was running on a PowerMac G5 [2-sockets, 2 cores each].) # svnlite info /usr/ports/ | grep 'Re[plv]' Relative URL: ^/head Repository Root: svn://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 495006 Last Changed Rev: 495006 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sun Mar 10 19:31:54 2019 Return-Path: Delivered-To: freebsd-ppc@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 EC341153EFC6 for ; Sun, 10 Mar 2019 19:31:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (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 C60EA8B102 for ; Sun, 10 Mar 2019 19:31:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: iWQZIVAVM1lHzK81d5mK2f9IZVvsM6sA.L8gW615QekPNph6drPqPVdqJRHIljk sZT7mPLdnhQZH6PuAHTKQvpXmVelC_R4QWhBW.nDjBALmSMVrCihE5uR7XXpOo0AuC1gikpGfKVn TZiKD0zDAb5uZAs6sEwlDUwVl3ya.b_2MzMJBpR7YcPL3iMzZshV__D4Vf3PjGMqge622xC_901u oCNPB50KZy1n7HOvcEjz9kpqwcPqYpbLj8LHYCDE7r0gdj.UyVngtrBASOUsgBKSu8m_DDcBHZVr uGqrTCPiXfhDqKBP5Le.K5ODx58v4FX9rPb.04IVF426llirmEGd9Rz4Vjb3nuWsJkq9kcT5YL5Y VRxQTePJ0C9.CtR6.RR9bMjltNP2Y_0gyxJROdnnNE8POewYlPZpJOAn0XTLfjKDU2bqproVUi5Z MjqQsbgLx_2BUTqIyBTD_CBFCyi0G1.MzJwATK4rZNSpPyufDWZzyfI6CFGNUn1tsixPt5r5lMLX sFjVKQJO5T.KfbnFa78fPm.e1qgM5ul1COPGJIbNShEfy..Cm4v3V2Xn2cAyPNVger9lfSsFXd5n 94JBZraTiT.VDPIuQwWWmjH1JROZV_tBGaUgI0oJ_r2pyP5pIOqNtQGj48UpYlaSh739t1B6MExf CYEDALFgzktQpo3o5sEhiTzkzypaBNMFH.Q6rrfaosWFcfflbbzDkj9Tfcv9XgqXvfcR3pULG5iz Ma_R0Z2g8VKwLva5NyBb6pSqDQ17xs3XyYENt_kNl8v7Gd1d5jvvNjn.RubqM8cdEfZ__pT_wewO 0K7q.HSd_rrNGzzEdk_I5dBKgUXdNhJ4a8J3KcSlifQvTn51uORSst9VLl7P1C50HRP9XSza_nEA H97BXQWsQi9C9rTrMzOvVH7bSkLEHqLjuvv9SxSvCDWz3PLpjs0Rd_wZVzqXcMv3yM4zZztHEA_S To0zMkTB9_gf9WF1EZe8Fgq_Bgs0HOpjfh9kJRBdkMY_bM3U4wodMJ8PO6AFJXmhGuABB4SgJj2g nQr6oensjGQdypcYb_SN7EkdME1FTlapjvFHISW_HiUXDKLVYZ8VlOQY4Og-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Sun, 10 Mar 2019 19:31:46 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp423.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0c2c6b569b01cd169bf0ce3d9e1fc29c for ; Sun, 10 Mar 2019 19:31:43 +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 12.2 \(3445.102.3\)) Subject: An FYI for 32-bit powerpc: : fsync: giving up on dirty [1st time Ive seen such messages] Message-Id: Date: Sun, 10 Mar 2019 12:31:41 -0700 To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: C60EA8B102 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.89)[0.889,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; NEURAL_SPAM_MEDIUM(0.90)[0.899,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(1.42)[ip: (4.94), ipnet: 66.163.184.0/21(1.23), asn: 36646(0.99), country: US(-0.07)]; NEURAL_SPAM_LONG(0.79)[0.794,0]; RCVD_IN_DNSWL_NONE(0.00)[147.185.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 19:31:54 -0000 While ports-mgmt/poudreire-devel was attempting a build of llvm80 on an old PowerMac G5 [2 sockets, 2 cores each] but running 32-bit FreeBSD, the system reported: Mar 10 00:41:56 FBSDG4S kernel: fsync: giving up on dirty (error =3D 35) = 0x23ae000: tag devfs, type VCHR Mar 10 00:41:56 FBSDG4S kernel: usecount 1, writecount 0, refcount = 55 rdev 0x248e400 Mar 10 00:41:56 FBSDG4S kernel: flags (VI_ACTIVE) Mar 10 00:41:56 FBSDG4S kernel: v_object 0x23582a0 ref 0 pages 2106 = cleanbuf 40 dirtybuf 13 Mar 10 00:41:56 FBSDG4S kernel: lock type devfs: EXCL by thread = 0x229ac3a0 (pid 74842, pkg-static, tid 100224) Mar 10 00:41:56 FBSDG4S kernel: dev ufs/FBSDG4Srootfs Mar 10 00:43:31 FBSDG4S kernel: fsync: giving up on dirty (error =3D 35) = 0x23ae000: tag devfs, type VCHR Mar 10 00:43:31 FBSDG4S kernel: usecount 1, writecount 0, refcount = 42 rdev 0x248e400 Mar 10 00:43:31 FBSDG4S kernel: flags (VI_ACTIVE) Mar 10 00:43:31 FBSDG4S kernel: v_object 0x23582a0 ref 0 pages 12562 = cleanbuf 27 dirtybuf 12 Mar 10 00:43:31 FBSDG4S kernel: lock type devfs: EXCL by thread = 0x229ac3a0 (pid 74842, pkg-static, tid 100224) Mar 10 00:43:31 FBSDG4S kernel: with exclusive waiters pending Mar 10 00:43:31 FBSDG4S kernel: dev ufs/FBSDG4Srootfs Mar 10 00:45:21 FBSDG4S kernel: fsync: giving up on dirty (error =3D 35) = 0x23ae000: tag devfs, type VCHR Mar 10 00:45:21 FBSDG4S kernel: usecount 1, writecount 0, refcount = 57 rdev 0x248e400 Mar 10 00:45:21 FBSDG4S kernel: flags (VI_ACTIVE) Mar 10 00:45:21 FBSDG4S kernel: v_object 0x23582a0 ref 0 pages 2930 = cleanbuf 30 dirtybuf 24 Mar 10 00:45:21 FBSDG4S kernel: lock type devfs: EXCL by thread = 0x229ac3a0 (pid 74842, pkg-static, tid 100224) Mar 10 00:45:21 FBSDG4S kernel: with exclusive waiters pending Mar 10 00:45:21 FBSDG4S kernel: dev ufs/FBSDG4Srootfs error=3D35 being FreeBSD's EAGAIN. This seems to be from: /* * If synchronous the caller expects us to completely resolve = all * dirty buffers in the system. Wait for in-progress I/O to * complete (which could include background bitmap writes), then * retry if dirty blocks still exist. */ if (ap->a_waitfor =3D=3D MNT_WAIT) { bufobj_wwait(bo, 0, 0); if (bo->bo_dirty.bv_cnt > 0) { /* * If we are unable to write any of these = buffers * then we fail now rather than trying endlessly * to write them out. */ TAILQ_FOREACH(bp, &bo->bo_dirty.bv_hd, b_bobufs) if ((error =3D bp->b_error) !=3D 0) break; if ((mp !=3D NULL && mp->mnt_secondary_writes > = 0) || (error =3D=3D 0 && --maxretry >=3D 0)) goto loop1; if (error =3D=3D 0) error =3D EAGAIN; } } BO_UNLOCK(bo); if (error !=3D 0) vn_printf(vp, "fsync: giving up on dirty (error =3D %d) = ", error); However, old PowerMac G5s currently require some form of hack in order to avoid sleeps getting stuck as things are. For all I know the messages could be tied to that context in some way. I've not seen such from 64-bit FreeBSD with 16 GiBytes of RAM on the same G5. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Tue Mar 12 19:20:39 2019 Return-Path: Delivered-To: freebsd-ppc@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 86438153BC07 for ; Tue, 12 Mar 2019 19:20:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (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 35F2E81EB5 for ; Tue, 12 Mar 2019 19:20:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: if2hHZwVM1m5FZ.uqOJ5TxeIQVsh7ETa._abkGnR8qqHHagbfyJ2oJBDGEAXCrw zxkqEhlM2fwfgDuc0eQ6oBhiO9sztFiWfYkd3DOSOAFv.m.o991sYwNw6nIo1GkF0q0LkvtooU1b RY6C_hc1oa2QtvuFFoJhlhY5tRBNjrQ2MQoLNTpwjOlHkT8pa5SxOhUuBLgSOJ6ab7Rl2OTMzV6k iVw7CZQ7dxj7pnjUyuJdP0YwCR2FGd8O7CajcmgNrte1dHkq4g0Ix7QS40P0Om1WeMOJt2bR6G7_ 2g5Ghe4T_wRTY055MIBbYAiUDL_utpkrozH.Xip5YOlnCWNKDOSoKApxIbCRM5bB_KRIWUGxVYt4 GHKXQSZB77sJqKqeWmOpvhwEhkKQiMkXohBz8M8W6LSC7f3hHo5Q9fxcbGWpRLP67L63LIPmhoMY 8pDH5TRNHZCaWjLNrpdoQZVU08_tuKFDhTPK2l2asheRy3q2UUzmxYJqlbZyJSrnFNU..7iNV7dx 4TgmDqAi4HM_SBGcsBEtEJ2gW7kCr0Xd6u8uomni94Gi8_kDqhTDrILnsaTuXc.Hm19dHJYgdqnK KVKSUFicBchcsseE6Gy7ZNADS.kKfN701LhvNUWap7ZhcR.B9BWoV_SHMRx1leCG3ohHf6gAC2uN U7o8YmDqBfAqc9yB73frWwU_P5Kfjh_xdhS1p7nNOlklgagtfysPU_xyQijhOWTtyMybRK0RpJzj BZC97BzozxQ8ua2f4QLye19JhfvZskY1BBYfJTYzUxFI5tiiku_msDDd1Imk8R4Vnk2dBtFFYfKy saS2WzBWTJoYbqCJh.FcczR5ow5grwYsjdFk6WLPRpvaxQYr5Zwd00J0j5hz36Ayra_Ni44P7Mbh wGaoN0uyuh_jz0wdRFU83E636bGkpUA_CWmde7w2WaRs2_0r3OcTidIV.nfktPlSV42u3JNgQw_w 6f7csv3_OJX7xvf4nnwAQ4PQVthKlgijvdLVPO8CR8xQZ8liENjBDYRR7LZnWvkzzLs6gYwRmJr2 1WqnU57shEwi_XzOctSfxXIwWl.e.nLHMWWV1uIz_0TJDUXu7g.1YO05hv.PeQOnxTmg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 12 Mar 2019 19:20:30 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp429.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a3f361f990b1a538e0ecfd35588740d2; Tue, 12 Mar 2019 19:20:29 +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 12.2 \(3445.102.3\)) Subject: powerpc64 head -r345044: WITH_LLVM_LIBUNWIND= based buildworld leads to thrown C++ exceptions segmentation faulting Message-Id: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> Date: Tue, 12 Mar 2019 12:20:28 -0700 To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 35F2E81EB5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.05)[-0.048,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.978,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.07)[ip: (-2.47), ipnet: 66.163.184.0/21(1.23), asn: 36646(0.98), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[205.186.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 19:20:39 -0000 [I sometimes experiment with building powerpc64 (and 32-bit) via more modern toolchains, here a amd64->powerpc64 cross build via system-clang (so 8.0.0).] buildworld with WITH_LLVM_LIBUNWIND=3D completes for powerpc64 (but not 32-bit powerpc). However, for a system installed from such for pwoerpc64, the following program (for example) gets a segmentation fault: # more ~/c_tests/exception_test.cpp=20 #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } (Note: the same a.out works under a WITHOUT_LLVM_LIBUNWIND=3D environment, that was patched for DW_CFA_remember_state and DW_CFA_restore_state handling, with the system built via devel/powerpc64-xtoolchain-gcc related materials. So the failure is on the system library does of things for the WITH_LLVM_LIBUNWIND=3D context.) Unfortunately: A) devel/gdb makes extensive use of thrown C++ exceptions and so does not work for a powerpc64 system based on WITH_LLVM_LIBUNWIND=3D . B) The world built is not using dwarf-2 so /usr/libexec/gdb is not handy/useful. C) CFLAGS+=3D-gdwarf-2 leads to system-clang having an Abort trap during buildworld's compile of gcrt1.s . (Reference material later, below.) D) lldb crashes in llvm_unreachable in lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() on powerpc64. (Reference material later, below.) So I've not managed to check the backtrace for the segmentation fault in the short example. For reference . . . For (C) ( -gdwarf-2 use ): QUOTES (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x000000000474afcf in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 #2 0x00000000046cd386 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 #3 0x00000000047394ba in __assert (func=3D, = file=3D, line=3D, failedexpr=3D) at /usr/src/lib/libc/gen/assert.c:51 #4 0x000000000429aa9f in resetRootFile () at = /usr/src/contrib/llvm/include/llvm/MC/MCDwarf.h:316 #5 parseDirectiveFile () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:3377 #6 parseStatement () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:2023 #7 0x000000000428cc12 in Run () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:884 #8 0x000000000163c649 in ExecuteAssembler () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:503 #9 cc1as_main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:589 #10 0x0000000001643d10 in ExecuteCC1Tool () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:312 #11 main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 void resetRootFile() { assert(Header.MCDwarfFiles.empty()); Header.RootFile.Name.clear(); Header.resetMD5Usage(); Header.HasSource =3D false; } --- lib/csu__L --- cc: error: unable to execute command: Abort trap (core dumped) cc: error: clang integrated assembler command failed due to signal (use = -v to see invocation) FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on LLVM = 8.0.0) Target: powerpc64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. cc: note: diagnostic msg: Error generating preprocessed source(s) - no = preprocessable inputs. *** [gcrt1.o] Error code 254 make[5]: stopped in /usr/src/lib/csu/powerpc64 .ERROR_TARGET=3D'gcrt1.o' = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/gcrt1.o.meta' .MAKE.LEVEL=3D'5' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'cc -gdwarf-2 -target powerpc64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe = -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -mlongcall = -DCRT_IRELOC_SUPPRESS -std=3Dgnu99 -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls = -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o gcrt1.o gcrt1.s;' .CURDIR=3D'/usr/src/lib/csu/powerpc64' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/lib/csu/powerpc64' .TARGETS=3D'all' = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc64' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20181221' = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/p= owerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lega= cy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_alt= binutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin= :/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/csu/powerpc64/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/csu/powerpc64/../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/csu/powerpc64/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH=3D'. /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common' 1 error END QUOTES For (D) (lldb): QUOTES CPU not supported UNREACHABLE executed at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192! Abort trap (core dumped) (gdb) bt #0 0x0000000813715208 in .__sys_thr_kill () at thr_kill.S:3 #1 0x00000008137147cc in __raise (s=3D) at = /usr/src/lib/libc/gen/raise.c:52 #2 0x000000081366b5d8 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 #3 0x0000000011df6fb8 in llvm::llvm_unreachable_internal () at = /usr/src/contrib/llvm/lib/Support/ErrorHandling.cpp:222 #4 0x00000000103aaaf8 in FreeBSDThread::GetRegisterContext () at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192 #5 0x00000000105807d4 in lldb_private::Thread::SetupForResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Thread.cpp:613 #6 0x0000000010571bc8 in lldb_private::ThreadList::WillResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/ThreadList.cpp:541 #7 0x00000000105da23c in lldb_private::Process::PrivateResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Process.cpp:3281 #8 0x00000000105a00c8 in lldb_private::Target::Launch () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Target.cpp:2922 #9 0x000000001073f550 in CommandObjectProcessLaunch::DoExecute () at = /usr/src/contrib/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:= 221 #10 0x00000000106c36c4 in lldb_private::CommandObjectParsed::Execute () = at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:975 #11 0x00000000106d8b44 in = lldb_private::CommandInterpreter::HandleCommand () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :1761 #12 0x00000000106da0a0 in = lldb_private::CommandInterpreter::IOHandlerInputComplete () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :2801 #13 0x00000000107c0a08 in lldb_private::IOHandlerEditline::Run () at = /usr/src/contrib/llvm/tools/lldb/source/Core/IOHandler.cpp:558 #14 0x0000000010346e5c in lldb_private::Debugger::ExecuteIOHandlers () = at /usr/src/contrib/llvm/tools/lldb/source/Core/Debugger.cpp:988 #15 0x00000000106c8ddc in = lldb_private::CommandInterpreter::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :3003 #16 0x000000001034feb4 in lldb::SBDebugger::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/API/SBDebugger.cpp:935 #17 0x00000000101de878 in Driver::MainLoop () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:756 #18 0x00000000101a0088 in main () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:936 lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() { if (!m_reg_context_sp) { m_posix_thread =3D nullptr; RegisterInfoInterface *reg_interface =3D nullptr; const ArchSpec &target_arch =3D = GetProcess()->GetTarget().GetArchitecture(); switch (target_arch.GetMachine()) { case llvm::Triple::aarch64: reg_interface =3D new RegisterInfoPOSIX_arm64(target_arch); break; case llvm::Triple::arm: reg_interface =3D new RegisterInfoPOSIX_arm(target_arch); break; case llvm::Triple::ppc: #ifndef __powerpc64__ reg_interface =3D new = RegisterContextFreeBSD_powerpc32(target_arch); break; #endif case llvm::Triple::ppc64: reg_interface =3D new = RegisterContextFreeBSD_powerpc64(target_arch); break; case llvm::Triple::mips64: reg_interface =3D new RegisterContextFreeBSD_mips64(target_arch); break; case llvm::Triple::x86: reg_interface =3D new RegisterContextFreeBSD_i386(target_arch); break; case llvm::Triple::x86_64: reg_interface =3D new RegisterContextFreeBSD_x86_64(target_arch); break; default: llvm_unreachable("CPU not supported"); } END QUOTES. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Tue Mar 12 21:05:36 2019 Return-Path: Delivered-To: freebsd-ppc@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 4F33B153E8EE for ; Tue, 12 Mar 2019 21:05:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (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 8418385D91 for ; Tue, 12 Mar 2019 21:05:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: w5gAGyUVM1nQGcRrwVvEuLZBhyi3RNXAoiES0GDqRulYmlj3NVWunsjlkug.y7I ISfSp51aqqIwhXCrsu1A0ZK_oMAGv8orp2HTd3hCkwbB6dPz68Sj2uk34zveA2HgvnB6hPObtUsH lcvC8BVnzXQCqaUAzeW4gJlaVFcySq0zd7hn_Zd9NMRFs1PYMAzsVtE3fp5UytkFBiuqKO.aSamc G_GpdFDNLCSCJYDJRj5ckWchqpKci05IB1KoBJaoFDvdkpcGaGvAIN.IYwnaLH8zJ6jXQfJAD488 Wb3buUIhZCebvD4NeYe3.j_Ii.oXE1SBzUB.3.2wQguQ6upEovYCmNopVPLmQJcIgSKlGNEtNSLJ n4LzlI0jZEszuDYgurn.JKMD7eoD6MKYa83fPki8pQ4Xqss8qr33EjkEqPNge6yYyIfETDSdhzuK tWzS5L8nAKDQDMYzIAY6Wpxcu9Mr6ZyJTUHxXITwjGe1hrDCByPW5OZcoyFdaRi9aCLUKU0waGaJ VpCIVjIxLtu5h.LekU9ImXiDSZkma88yIcKEEy_.o1VUjqI6PYmOK4Mm3X4y.AUUqRFzrJvZJQYo EuQRAdS5RFKmpb2karRGDXegHQH_evp3t5lgqD3PyWQsmFJ.SHEtPu.99e9ITnXTmmoPuAu1dJR9 zt6ejHItSTRmvBoPqUC9dEnCkrBNImSQBw6l.qPhGY8loeexlhqjTnlUNnA4sjmBlKq05yayQhbW pGbi7pF_Fo37W6ufHbW70CQSISWargucZmwjieDNReorjr0p6EwFk266VhcGIoVz9ZAATz0i5dah cu58qAb8DVSuTzs41WoZjC0ewGQJcDWnG_SHUZ.CkBEW0oo_Es_QUogJRjqKnjNteRImdLDCkhve 7w.1WSh9PCKAqqOQn.z1DKyv53Y7RUHuYl8vY7ukQv.8uOuJDKWC5cRXlAgHI_neqpJ9vg97MNlF pB6QU4LbrkA5T.yK0S_vMKnBi_JW6n8jmJ9p1Qs9gg8nT6bLYQONymNAu333f2FA1A1okosB9KHR qfm9SOUu5.ZdB6FeMFqolGMq3XaPuV1rJBfcDG_fmRM6nLLAMgMVujtB654gP0d17BCA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 12 Mar 2019 21:05:32 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp407.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8cc80f3329a5ccc5ed505fabab741b5c; Tue, 12 Mar 2019 21:05:29 +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 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r345044: WITH_LLVM_LIBUNWIND= based buildworld leads to thrown C++ exceptions segmentation faulting Date: Tue, 12 Mar 2019 14:05:27 -0700 References: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Toolchain In-Reply-To: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 8418385D91 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.43)[-0.430,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.26)[ip: (-3.45), ipnet: 66.163.184.0/21(1.23), asn: 36646(0.98), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[205.186.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 21:05:36 -0000 [I got some libunwind debug output from the a.out run. This and a disassembly of main suggest an instruction pointer address is too large by 0x4 for jumping to the code that would call __cxa_begin_catch .] > On 2019-Mar-12, at 12:20, Mark Millard wrote: >=20 > [I sometimes experiment with building powerpc64 (and 32-bit) via > more modern toolchains, here a amd64->powerpc64 cross build via > system-clang (so 8.0.0).] >=20 > buildworld with WITH_LLVM_LIBUNWIND=3D completes for powerpc64 > (but not 32-bit powerpc). However, for a system installed > from such for pwoerpc64, the following program (for example) > gets a segmentation fault: >=20 > # more ~/c_tests/exception_test.cpp=20 > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} > return 0; > } >=20 > (Note: the same a.out works under a WITHOUT_LLVM_LIBUNWIND=3D > environment, that was patched for DW_CFA_remember_state and > DW_CFA_restore_state handling, with the system built via > devel/powerpc64-xtoolchain-gcc related materials. So the > failure is on the system library does of things for the > WITH_LLVM_LIBUNWIND=3D context.) >=20 > Unfortunately: >=20 > A) devel/gdb makes extensive use of thrown C++ exceptions > and so does not work for a powerpc64 system based on > WITH_LLVM_LIBUNWIND=3D . >=20 > B) The world built is not using dwarf-2 so /usr/libexec/gdb > is not handy/useful. >=20 > C) CFLAGS+=3D-gdwarf-2 leads to system-clang having an Abort > trap during buildworld's compile of gcrt1.s . (Reference > material later, below.) >=20 > D) lldb crashes in llvm_unreachable in > lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() > on powerpc64. (Reference material later, below.) >=20 > So I've not managed to check the backtrace for the > segmentation fault in the short example. >=20 >=20 >=20 > For reference . . . >=20 >=20 > For (C) ( -gdwarf-2 use ): >=20 > QUOTES > (gdb) bt > #0 thr_kill () at thr_kill.S:3 > #1 0x000000000474afcf in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 > #2 0x00000000046cd386 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 > #3 0x00000000047394ba in __assert (func=3D, = file=3D, line=3D, failedexpr=3D) at /usr/src/lib/libc/gen/assert.c:51 > #4 0x000000000429aa9f in resetRootFile () at = /usr/src/contrib/llvm/include/llvm/MC/MCDwarf.h:316 > #5 parseDirectiveFile () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:3377 > #6 parseStatement () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:2023 > #7 0x000000000428cc12 in Run () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:884 > #8 0x000000000163c649 in ExecuteAssembler () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:503 > #9 cc1as_main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:589 > #10 0x0000000001643d10 in ExecuteCC1Tool () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:312 > #11 main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 >=20 > void resetRootFile() { > assert(Header.MCDwarfFiles.empty()); > Header.RootFile.Name.clear(); > Header.resetMD5Usage(); > Header.HasSource =3D false; > } >=20 > --- lib/csu__L --- > cc: error: unable to execute command: Abort trap (core dumped) > cc: error: clang integrated assembler command failed due to signal = (use -v to see invocation) > FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on = LLVM 8.0.0) > Target: powerpc64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin > cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. > cc: note: diagnostic msg: Error generating preprocessed source(s) - no = preprocessable inputs. > *** [gcrt1.o] Error code 254 >=20 > make[5]: stopped in /usr/src/lib/csu/powerpc64 > .ERROR_TARGET=3D'gcrt1.o' > = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/gcrt1.o.meta' > .MAKE.LEVEL=3D'5' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > _ERROR_CMD=3D'cc -gdwarf-2 -target powerpc64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe = -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -mlongcall = -DCRT_IRELOC_SUPPRESS -std=3Dgnu99 -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls = -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o gcrt1.o gcrt1.s;' > .CURDIR=3D'/usr/src/lib/csu/powerpc64' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/lib/csu/powerpc64' > .TARGETS=3D'all' > = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/tmp' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'powerpc' > MACHINE_ARCH=3D'powerpc64' > MAKEOBJDIRPREFIX=3D'' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20181221' > = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/p= owerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lega= cy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_alt= binutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin= :/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/src' > = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64' > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/csu/powerpc64/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/csu/powerpc64/../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/csu/powerpc64/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' > .PATH=3D'. /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common' > 1 error > END QUOTES >=20 >=20 > For (D) (lldb): >=20 > QUOTES > CPU not supported > UNREACHABLE executed at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192! > Abort trap (core dumped) >=20 > (gdb) bt > #0 0x0000000813715208 in .__sys_thr_kill () at thr_kill.S:3 > #1 0x00000008137147cc in __raise (s=3D) at = /usr/src/lib/libc/gen/raise.c:52 > #2 0x000000081366b5d8 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 > #3 0x0000000011df6fb8 in llvm::llvm_unreachable_internal () at = /usr/src/contrib/llvm/lib/Support/ErrorHandling.cpp:222 > #4 0x00000000103aaaf8 in FreeBSDThread::GetRegisterContext () at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192 > #5 0x00000000105807d4 in lldb_private::Thread::SetupForResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Thread.cpp:613 > #6 0x0000000010571bc8 in lldb_private::ThreadList::WillResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/ThreadList.cpp:541 > #7 0x00000000105da23c in lldb_private::Process::PrivateResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Process.cpp:3281 > #8 0x00000000105a00c8 in lldb_private::Target::Launch () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Target.cpp:2922 > #9 0x000000001073f550 in CommandObjectProcessLaunch::DoExecute () at = /usr/src/contrib/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:= 221 > #10 0x00000000106c36c4 in lldb_private::CommandObjectParsed::Execute = () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:975 > #11 0x00000000106d8b44 in = lldb_private::CommandInterpreter::HandleCommand () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :1761 > #12 0x00000000106da0a0 in = lldb_private::CommandInterpreter::IOHandlerInputComplete () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :2801 > #13 0x00000000107c0a08 in lldb_private::IOHandlerEditline::Run () at = /usr/src/contrib/llvm/tools/lldb/source/Core/IOHandler.cpp:558 > #14 0x0000000010346e5c in lldb_private::Debugger::ExecuteIOHandlers () = at /usr/src/contrib/llvm/tools/lldb/source/Core/Debugger.cpp:988 > #15 0x00000000106c8ddc in = lldb_private::CommandInterpreter::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :3003 > #16 0x000000001034feb4 in lldb::SBDebugger::RunCommandInterpreter () = at /usr/src/contrib/llvm/tools/lldb/source/API/SBDebugger.cpp:935 > #17 0x00000000101de878 in Driver::MainLoop () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:756 > #18 0x00000000101a0088 in main () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:936 >=20 > lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() { > if (!m_reg_context_sp) { > m_posix_thread =3D nullptr; >=20 > RegisterInfoInterface *reg_interface =3D nullptr; > const ArchSpec &target_arch =3D = GetProcess()->GetTarget().GetArchitecture(); >=20 > switch (target_arch.GetMachine()) { > case llvm::Triple::aarch64: > reg_interface =3D new RegisterInfoPOSIX_arm64(target_arch); > break; > case llvm::Triple::arm: > reg_interface =3D new RegisterInfoPOSIX_arm(target_arch); > break; > case llvm::Triple::ppc: > #ifndef __powerpc64__ > reg_interface =3D new = RegisterContextFreeBSD_powerpc32(target_arch); > break; > #endif > case llvm::Triple::ppc64: > reg_interface =3D new = RegisterContextFreeBSD_powerpc64(target_arch); > break; > case llvm::Triple::mips64: > reg_interface =3D new RegisterContextFreeBSD_mips64(target_arch); > break; > case llvm::Triple::x86: > reg_interface =3D new RegisterContextFreeBSD_i386(target_arch); > break; > case llvm::Triple::x86_64: > reg_interface =3D new RegisterContextFreeBSD_x86_64(target_arch); > break; > default: > llvm_unreachable("CPU not supported"); > } > END QUOTES. I ran into libunwind having LIBUNWIND_PRINT_UNWINDING and LIBUNWIND_PRINT_APIS so I can report for the segmentation fault: # export LIBUNWIND_PRINT_UNWINDING=3D"" # export LIBUNWIND_PRINT_APIS=3D"" # ./a.out libunwind: _Unwind_RaiseException(ex_obj=3D0x810043060) libunwind: unw_init_local(cursor=3D0x3fffffffffffcb68, = context=3D0x3fffffffffffd100) libunwind: unw_step(cursor=3D0x3fffffffffffcb68) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffd850) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb68, = &buf=3D0x3fffffffffffd648, bufLen=3D512) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = &value=3D0x3fffffffffffd638) libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x81019d954, = start_ip=3D0x81019d860, func=3D.anonymous., lsda=3D0x0, personality=3D0x0 libunwind: unw_step(cursor=3D0x3fffffffffffcb68) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffd850) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb68, = &buf=3D0x3fffffffffffd648, bufLen=3D512) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = &value=3D0x3fffffffffffd638) libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x10000da8, = start_ip=3D0x10000d64, func=3D.anonymous., lsda=3D0x10000f84, = personality=3D0x8101b5360 libunwind: unwind_phase1(ex_ojb=3D0x810043060): calling personality = function 0x8101b5360 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffc970) libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb68) = =3D> 0x10000f84 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffc8b0) libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb68) =3D> = 0x10000d64 libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = &value=3D0x3fffffffffffc8e8) libunwind: _Unwind_GetIP(context=3D0x3fffffffffffcb68) =3D> 0x10000da8 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffc8a0) libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb68) =3D> = 0x10000d64 libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-2, = &value=3D0x3fffffffffffd848) libunwind: unwind_phase1(ex_ojb=3D0x810043060): _URC_HANDLER_FOUND libunwind: unw_init_local(cursor=3D0x3fffffffffffcb68, = context=3D0x3fffffffffffd100) libunwind: unwind_phase2(ex_ojb=3D0x810043060) libunwind: unw_step(cursor=3D0x3fffffffffffcb68) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-2, = &value=3D0x3fffffffffffca78) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffca30) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb68, = &buf=3D0x3fffffffffffc830, bufLen=3D512) libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x81019d860, = func=3D.anonymous., sp=3D0x3fffffffffffd900, lsda=3D0x0, personality=3D0x0= libunwind: unw_step(cursor=3D0x3fffffffffffcb68) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-2, = &value=3D0x3fffffffffffca78) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffca30) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb68, = &buf=3D0x3fffffffffffc830, bufLen=3D512) libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x10000d64, = func=3D.anonymous., sp=3D0x3fffffffffffd9a0, lsda=3D0x10000f84, = personality=3D0x8101b5360 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffc630) libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb68) = =3D> 0x10000f84 libunwind: _Unwind_SetIP(context=3D0x3fffffffffffcb68, value=3D0x10000dac)= libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = value=3D0x10000dac) libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb68, reg=3D3, = value=3D0x810043060) libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb68, regNum=3D3, = value=3D0x810043060) libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb68, reg=3D4, = value=3D0x1) libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb68, regNum=3D4, = value=3D0x1) libunwind: unwind_phase2(ex_ojb=3D0x810043060): _URC_INSTALL_CONTEXT libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = &value=3D0x3fffffffffffc830) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-2, = &value=3D0x3fffffffffffca78) libunwind: unwind_phase2(ex_ojb=3D0x810043060): re-entering user code = with ip=3D0x10000dac, sp=3D0x3fffffffffffd9a0 libunwind: unw_resume(cursor=3D0x3fffffffffffcb68) Segmentation fault (core dumped) Note that the 0x10000dac address below is after the "ld r2,40(r1)" that sets up r2's value for use in the 00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3 routine. The ip value reported by unwind_phase2 appears to too large by 0x4 . (gdb) disass main Dump of assembler code for function main(): 0x0000000010000d64 <+0>: mflr r0 0x0000000010000d68 <+4>: std r31,-8(r1) 0x0000000010000d6c <+8>: std r0,16(r1) 0x0000000010000d70 <+12>: stdu r1,-128(r1) 0x0000000010000d74 <+16>: mr r31,r1 0x0000000010000d78 <+20>: li r3,8 0x0000000010000d7c <+24>: bl 0x100007a0 = <00000018.plt_call.__cxa_allocate_exception@@CXXABI_1.3> 0x0000000010000d80 <+28>: ld r2,40(r1) 0x0000000010000d84 <+32>: nop 0x0000000010000d88 <+36>: ld r4,-32728(r2) 0x0000000010000d8c <+40>: addi r4,r4,16 0x0000000010000d90 <+44>: std r4,0(r3) 0x0000000010000d94 <+48>: nop 0x0000000010000d98 <+52>: nop 0x0000000010000d9c <+56>: ld r4,-32720(r2) 0x0000000010000da0 <+60>: ld r5,-32712(r2) 0x0000000010000da4 <+64>: bl 0x10000800 = <00000018.plt_call.__cxa_throw@@CXXABI_1.3> 0x0000000010000da8 <+68>: ld r2,40(r1) 0x0000000010000dac <+72>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> 0x0000000010000db0 <+76>: ld r2,40(r1) 0x0000000010000db4 <+80>: bl 0x100007e0 = <00000018.plt_call.__cxa_end_catch@@CXXABI_1.3> 0x0000000010000db8 <+84>: ld r2,40(r1) 0x0000000010000dbc <+88>: li r3,0 0x0000000010000dc0 <+92>: addi r1,r1,128 0x0000000010000dc4 <+96>: ld r0,16(r1) 0x0000000010000dc8 <+100>: ld r31,-8(r1) 0x0000000010000dcc <+104>: mtlr r0 0x0000000010000dd0 <+108>: blr 0x0000000010000dd4 <+112>: .long 0x0 0x0000000010000dd8 <+116>: .long 0x0 0x0000000010000ddc <+120>: .long 0x0 End of assembler dump. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Tue Mar 12 23:34:56 2019 Return-Path: Delivered-To: freebsd-ppc@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 5FD541543218 for ; Tue, 12 Mar 2019 23:34:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.42]) (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 95FE58C1A1 for ; Tue, 12 Mar 2019 23:34:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 173ZuHAVM1kWY8iVPElFVfo8WPG5n5feEwui3Lon6Uoh3byahgSu1HztApQSWQC U2fOKOBwGorfT8.L3JY39g0GhPVF2w8Z8M_rjcm1txFDp3LLKRzQZJ9BT33UYQy1Ibh12NDhTYqj 1z4HRUZKkFyUNJ3Bza2AQSOJUq04ArdktQkby4mP_IDKh2ZO1LdeZP40lW8igkq19G.uN8oXW5.A AfzPZmXfGfAuXZjn_pFkDp7Av72CVtE.ML9Xqx5T4mOQreH.02yA4h7DWw2v0BjzTv.qVWGRV3RA Be7CA5pkk80rW_U9Fq4FX2vDgW0rygW52Bx.zc_idRiqAV7ulVw.3XXz3BLtF9Qw5ymfyy5tmUbJ S_BLIWW3DT6tbOASD79A3vUq_tJXJLW.hrv3lb1Kks_qlgAyhkHs20TDhWOTD88Df_ssUMtL1S1s VkZDRW4vF9SGf2TCPoWsCgkT0zfJ53hNcH.0j.TpF34Eslzk.PlVPjhfiNjt3oBn8_Bi7nJzCj6f tg_tc8c4TF2rRAp3IVHNctwVRItwFa5A5J91FC0s72k9hlZ0_O8yHw3NfsWSQyO52WEGtC7WJMbo zh_Sh8UqRzK6o.wzf8lTFBV3Rcxvx818Ard3oqIRi1rKF_yGhVJ_jYb4sYgV9D.1Xsn.y85.8kwE lf0jZ_Rah30dsGbZJWFneiITu_lYOZEPa_Ctuxml5YmGoj5arJae0jczTuGNRflEl9ojCSV3eZVm RLU.9Fi6yvkqlb8SD5ZdKTY3Tvp0ijA6KXVAAeqB4jZiz_e2JltHTBPjbmbfwQDejHlKf08MEPl1 kMSLa5u52rNGmnHDJP330jmwMbBtzIKtdOGgnp0HLp_gGDYsUE6IKwefXRFLifvIp6fb_8pjyve9 wa8cZkgRJNt9vNFBfIV9h3xEPotmMVKS06FeFUmjziVjQ0t2KL5oWRp9MCFt2oMkJIvBxtkbLaWA KLItdKcpB6J90IcZnajym210HnJnM1gks.1sQ4vPdqntdTSLRAtHYNoJtHS_DvSURlMiF8DAUCwn Bfb_7CJhxaWm1WPVhqX3LGVh6RSwcyCKaQz6J5TWuo0D6Vg10Xu7CONqqUWIxyi_FPbs80w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Tue, 12 Mar 2019 23:34:53 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp427.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f646c7f5135d87e0ef548952e610ce40; Tue, 12 Mar 2019 23:34:50 +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 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r345044: WITH_LLVM_LIBUNWIND= based buildworld leads to thrown C++ exceptions segmentation faulting Date: Tue, 12 Mar 2019 16:34:47 -0700 References: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Toolchain In-Reply-To: Message-Id: <3B37B7B0-DCB0-4984-AABD-4C3448DA7D56@yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 95FE58C1A1 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.852,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.37)[ip: (4.33), ipnet: 74.6.128.0/21(1.43), asn: 26101(1.14), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.94)[0.943,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.85)[0.846,0]; RCVD_IN_DNSWL_NONE(0.00)[42.132.6.74.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 23:34:56 -0000 [The unoptimized code is more revealing so I switch to presenting it and what it lead me to: more detail on r2 being mishandled.] > On 2019-Mar-12, at 14:05, Mark Millard wrote: >=20 > [I got some libunwind debug output from the a.out run. This > and a disassembly of main suggest an instruction pointer > address is too large by 0x4 for jumping to the code that > would call __cxa_begin_catch .] >=20 >> On 2019-Mar-12, at 12:20, Mark Millard wrote: >>=20 >> [I sometimes experiment with building powerpc64 (and 32-bit) via >> more modern toolchains, here a amd64->powerpc64 cross build via >> system-clang (so 8.0.0).] >>=20 >> buildworld with WITH_LLVM_LIBUNWIND=3D completes for powerpc64 >> (but not 32-bit powerpc). However, for a system installed >> from such for pwoerpc64, the following program (for example) >> gets a segmentation fault: >>=20 >> # more ~/c_tests/exception_test.cpp=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >> (Note: the same a.out works under a WITHOUT_LLVM_LIBUNWIND=3D >> environment, that was patched for DW_CFA_remember_state and >> DW_CFA_restore_state handling, with the system built via >> devel/powerpc64-xtoolchain-gcc related materials. So the >> failure is on the system library does of things for the >> WITH_LLVM_LIBUNWIND=3D context.) >>=20 >> Unfortunately: >>=20 >> A) devel/gdb makes extensive use of thrown C++ exceptions >> and so does not work for a powerpc64 system based on >> WITH_LLVM_LIBUNWIND=3D . >>=20 >> B) The world built is not using dwarf-2 so /usr/libexec/gdb >> is not handy/useful. >>=20 >> C) CFLAGS+=3D-gdwarf-2 leads to system-clang having an Abort >> trap during buildworld's compile of gcrt1.s . (Reference >> material later, below.) >>=20 >> D) lldb crashes in llvm_unreachable in >> lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() >> on powerpc64. (Reference material later, below.) >>=20 >> So I've not managed to check the backtrace for the >> segmentation fault in the short example. >>=20 >>=20 >>=20 >> For reference . . . >>=20 >>=20 >> For (C) ( -gdwarf-2 use ): >>=20 >> QUOTES >> (gdb) bt >> #0 thr_kill () at thr_kill.S:3 >> #1 0x000000000474afcf in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 >> #2 0x00000000046cd386 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 >> #3 0x00000000047394ba in __assert (func=3D, = file=3D, line=3D, failedexpr=3D) at /usr/src/lib/libc/gen/assert.c:51 >> #4 0x000000000429aa9f in resetRootFile () at = /usr/src/contrib/llvm/include/llvm/MC/MCDwarf.h:316 >> #5 parseDirectiveFile () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:3377 >> #6 parseStatement () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:2023 >> #7 0x000000000428cc12 in Run () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:884 >> #8 0x000000000163c649 in ExecuteAssembler () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:503 >> #9 cc1as_main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:589 >> #10 0x0000000001643d10 in ExecuteCC1Tool () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:312 >> #11 main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 >>=20 >> void resetRootFile() { >> assert(Header.MCDwarfFiles.empty()); >> Header.RootFile.Name.clear(); >> Header.resetMD5Usage(); >> Header.HasSource =3D false; >> } >>=20 >> --- lib/csu__L --- >> cc: error: unable to execute command: Abort trap (core dumped) >> cc: error: clang integrated assembler command failed due to signal = (use -v to see invocation) >> FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on = LLVM 8.0.0) >> Target: powerpc64-unknown-freebsd13.0 >> Thread model: posix >> InstalledDir: /usr/bin >> cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. >> cc: note: diagnostic msg: Error generating preprocessed source(s) - = no preprocessable inputs. >> *** [gcrt1.o] Error code 254 >>=20 >> make[5]: stopped in /usr/src/lib/csu/powerpc64 >> .ERROR_TARGET=3D'gcrt1.o' >> = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/gcrt1.o.meta' >> .MAKE.LEVEL=3D'5' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> _ERROR_CMD=3D'cc -gdwarf-2 -target powerpc64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe = -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -mlongcall = -DCRT_IRELOC_SUPPRESS -std=3Dgnu99 -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls = -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o gcrt1.o gcrt1.s;' >> .CURDIR=3D'/usr/src/lib/csu/powerpc64' >> .MAKE=3D'make' >> = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/lib/csu/powerpc64' >> .TARGETS=3D'all' >> = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/tmp' >> LD_LIBRARY_PATH=3D'' >> MACHINE=3D'powerpc' >> MACHINE_ARCH=3D'powerpc64' >> MAKEOBJDIRPREFIX=3D'' >> MAKESYSPATH=3D'/usr/src/share/mk' >> MAKE_VERSION=3D'20181221' >> = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/p= owerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lega= cy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_alt= binutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin= :/bin:/usr/sbin:/usr/bin' >> SRCTOP=3D'/usr/src' >> = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64' >> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/csu/powerpc64/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/csu/powerpc64/../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/csu/powerpc64/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' >> .PATH=3D'. /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common' >> 1 error >> END QUOTES >>=20 >>=20 >> For (D) (lldb): >>=20 >> QUOTES >> CPU not supported >> UNREACHABLE executed at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192! >> Abort trap (core dumped) >>=20 >> (gdb) bt >> #0 0x0000000813715208 in .__sys_thr_kill () at thr_kill.S:3 >> #1 0x00000008137147cc in __raise (s=3D) at = /usr/src/lib/libc/gen/raise.c:52 >> #2 0x000000081366b5d8 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 >> #3 0x0000000011df6fb8 in llvm::llvm_unreachable_internal () at = /usr/src/contrib/llvm/lib/Support/ErrorHandling.cpp:222 >> #4 0x00000000103aaaf8 in FreeBSDThread::GetRegisterContext () at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192 >> #5 0x00000000105807d4 in lldb_private::Thread::SetupForResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Thread.cpp:613 >> #6 0x0000000010571bc8 in lldb_private::ThreadList::WillResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/ThreadList.cpp:541 >> #7 0x00000000105da23c in lldb_private::Process::PrivateResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Process.cpp:3281 >> #8 0x00000000105a00c8 in lldb_private::Target::Launch () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Target.cpp:2922 >> #9 0x000000001073f550 in CommandObjectProcessLaunch::DoExecute () at = /usr/src/contrib/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:= 221 >> #10 0x00000000106c36c4 in lldb_private::CommandObjectParsed::Execute = () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:975 >> #11 0x00000000106d8b44 in = lldb_private::CommandInterpreter::HandleCommand () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :1761 >> #12 0x00000000106da0a0 in = lldb_private::CommandInterpreter::IOHandlerInputComplete () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :2801 >> #13 0x00000000107c0a08 in lldb_private::IOHandlerEditline::Run () at = /usr/src/contrib/llvm/tools/lldb/source/Core/IOHandler.cpp:558 >> #14 0x0000000010346e5c in lldb_private::Debugger::ExecuteIOHandlers = () at /usr/src/contrib/llvm/tools/lldb/source/Core/Debugger.cpp:988 >> #15 0x00000000106c8ddc in = lldb_private::CommandInterpreter::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :3003 >> #16 0x000000001034feb4 in lldb::SBDebugger::RunCommandInterpreter () = at /usr/src/contrib/llvm/tools/lldb/source/API/SBDebugger.cpp:935 >> #17 0x00000000101de878 in Driver::MainLoop () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:756 >> #18 0x00000000101a0088 in main () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:936 >>=20 >> lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() { >> if (!m_reg_context_sp) { >> m_posix_thread =3D nullptr; >>=20 >> RegisterInfoInterface *reg_interface =3D nullptr; >> const ArchSpec &target_arch =3D = GetProcess()->GetTarget().GetArchitecture(); >>=20 >> switch (target_arch.GetMachine()) { >> case llvm::Triple::aarch64: >> reg_interface =3D new RegisterInfoPOSIX_arm64(target_arch); >> break; >> case llvm::Triple::arm: >> reg_interface =3D new RegisterInfoPOSIX_arm(target_arch); >> break; >> case llvm::Triple::ppc: >> #ifndef __powerpc64__ >> reg_interface =3D new = RegisterContextFreeBSD_powerpc32(target_arch); >> break; >> #endif >> case llvm::Triple::ppc64: >> reg_interface =3D new = RegisterContextFreeBSD_powerpc64(target_arch); >> break; >> case llvm::Triple::mips64: >> reg_interface =3D new RegisterContextFreeBSD_mips64(target_arch); >> break; >> case llvm::Triple::x86: >> reg_interface =3D new RegisterContextFreeBSD_i386(target_arch); >> break; >> case llvm::Triple::x86_64: >> reg_interface =3D new RegisterContextFreeBSD_x86_64(target_arch); >> break; >> default: >> llvm_unreachable("CPU not supported"); >> } >> END QUOTES. >=20 >=20 >=20 > I ran into libunwind having LIBUNWIND_PRINT_UNWINDING and > LIBUNWIND_PRINT_APIS so I can report for the segmentation > fault: >=20 > # export LIBUNWIND_PRINT_UNWINDING=3D"" > # export LIBUNWIND_PRINT_APIS=3D"" > # ./a.out > . . . Using unoptimized code instead: # c++ -g exception_test.cpp libunwind: __register_frame_info(0x137d6610, 0x13ae3150) libunwind: __register_frame_info(0x137d6610, 0x13ae3150) libunwind: __deregister_frame_info(0x137d6610) libunwind: __deregister_frame_info(0x137d6610) # ./a.out libunwind: _Unwind_RaiseException(ex_obj=3D0x810043060) libunwind: unw_init_local(cursor=3D0x3fffffffffffcb48, = context=3D0x3fffffffffffd0e0) libunwind: unw_step(cursor=3D0x3fffffffffffcb48) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffd830) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffd628, bufLen=3D512) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffd618) libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x81019d954, = start_ip=3D0x81019d860, func=3D.anonymous., lsda=3D0x0, personality=3D0x0 libunwind: unw_step(cursor=3D0x3fffffffffffcb48) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffd830) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffd628, bufLen=3D512) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffd618) libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x10000dac, = start_ip=3D0x10000d64, func=3D.anonymous., lsda=3D0x10000fe0, = personality=3D0x8101b5360 libunwind: unwind_phase1(ex_ojb=3D0x810043060): calling personality = function 0x8101b5360 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc950) libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb48) = =3D> 0x10000fe0 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc890) libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb48) =3D> = 0x10000d64 libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffc8c8) libunwind: _Unwind_GetIP(context=3D0x3fffffffffffcb48) =3D> 0x10000dac libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc880) libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb48) =3D> = 0x10000d64 libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffd828) libunwind: unwind_phase1(ex_ojb=3D0x810043060): _URC_HANDLER_FOUND libunwind: unw_init_local(cursor=3D0x3fffffffffffcb48, = context=3D0x3fffffffffffd0e0) libunwind: unwind_phase2(ex_ojb=3D0x810043060) libunwind: unw_step(cursor=3D0x3fffffffffffcb48) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffca10) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffc810, bufLen=3D512) libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x81019d860, = func=3D.anonymous., sp=3D0x3fffffffffffd8e0, lsda=3D0x0, personality=3D0x0= libunwind: unw_step(cursor=3D0x3fffffffffffcb48) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffca10) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffc810, bufLen=3D512) libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x10000d64, = func=3D.anonymous., sp=3D0x3fffffffffffd980, lsda=3D0x10000fe0, = personality=3D0x8101b5360 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc610) libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb48) = =3D> 0x10000fe0 libunwind: _Unwind_SetIP(context=3D0x3fffffffffffcb48, value=3D0x10000db4)= libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = value=3D0x10000db4) libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb48, reg=3D3, = value=3D0x810043060) libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D3, = value=3D0x810043060) libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb48, reg=3D4, = value=3D0x1) libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D4, = value=3D0x1) libunwind: unwind_phase2(ex_ojb=3D0x810043060): _URC_INSTALL_CONTEXT libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffc810) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) libunwind: unwind_phase2(ex_ojb=3D0x810043060): re-entering user code = with ip=3D0x10000db4, sp=3D0x3fffffffffffd980 libunwind: unw_resume(cursor=3D0x3fffffffffffcb48) Segmentation fault (core dumped) The below shows that the 0x10000db4 in this case seems right --and also that the code sequence does not set r2. Apparently the throw handling was supposed to set it so the optimized code skips setting it. (Later below it seems r2 should have been set by something but was not correctly set.) (gdb) disass main Dump of assembler code for function main(): 0x0000000010000d64 <+0>: mflr r0 0x0000000010000d68 <+4>: std r31,-8(r1) 0x0000000010000d6c <+8>: std r0,16(r1) 0x0000000010000d70 <+12>: stdu r1,-160(r1) 0x0000000010000d74 <+16>: mr r31,r1 0x0000000010000d78 <+20>: li r3,0 0x0000000010000d7c <+24>: stw r3,148(r31) 0x0000000010000d80 <+28>: li r3,8 0x0000000010000d84 <+32>: bl 0x100007a0 = <00000018.plt_call.__cxa_allocate_exception@@CXXABI_1.3> 0x0000000010000d88 <+36>: ld r2,40(r1) 0x0000000010000d8c <+40>: std r3,112(r31) 0x0000000010000d90 <+44>: bl 0x10000e00 = 0x0000000010000d94 <+48>: nop 0x0000000010000d98 <+52>: ld r4,-32728(r2) 0x0000000010000d9c <+56>: nop 0x0000000010000da0 <+60>: ld r5,-32720(r2) 0x0000000010000da4 <+64>: ld r3,112(r31) 0x0000000010000da8 <+68>: bl 0x10000800 = <00000018.plt_call.__cxa_throw@@CXXABI_1.3> 0x0000000010000dac <+72>: ld r2,40(r1) 0x0000000010000db0 <+76>: b 0x10000df4 0x0000000010000db4 <+80>: mr r5,r4 0x0000000010000db8 <+84>: std r3,136(r31) 0x0000000010000dbc <+88>: stw r5,132(r31) 0x0000000010000dc0 <+92>: b 0x10000dc4 0x0000000010000dc4 <+96>: ld r3,136(r31) 0x0000000010000dc8 <+100>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> 0x0000000010000dcc <+104>: ld r2,40(r1) 0x0000000010000dd0 <+108>: std r3,120(r31) 0x0000000010000dd4 <+112>: bl 0x100007e0 = <00000018.plt_call.__cxa_end_catch@@CXXABI_1.3> 0x0000000010000dd8 <+116>: ld r2,40(r1) 0x0000000010000ddc <+120>: li r3,0 0x0000000010000de0 <+124>: addi r1,r1,160 0x0000000010000de4 <+128>: ld r0,16(r1) 0x0000000010000de8 <+132>: ld r31,-8(r1) 0x0000000010000dec <+136>: mtlr r0 0x0000000010000df0 <+140>: blr 0x0000000010000df4 <+144>: .long 0x0 0x0000000010000df8 <+148>: .long 0x0 0x0000000010000dfc <+152>: .long 0x0 End of assembler dump. Notably lr seems to be: 0x10000dcc which is just after: bl 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> Note also the pc, r12, and ctr all having the failure address: 0x81042b900 . #0 0x000000081042b900 in ?? () from /lib/libc.so.7 (gdb) x/32i 0x000000081042b8F0 0x81042b8f0 : .long 0x8 0x81042b8f4 : vmrglh v1,v30,v7 0x81042b8f8: .long 0x8 0x81042b8fc: vsubeuqm v1,v30,v7,v17 =3D> 0x81042b900: .long 0x8 0x81042b904: vpmsumw v1,v30,v7 0x81042b908 <_citrus_bcs_skip_ws_len@got.plt>: .long 0x8 0x81042b90c <_citrus_bcs_skip_ws_len@got.plt+4>: .long 0x103e3c92 0x81042b910: .long 0x8 0x81042b914: .long 0x103e3c9b 0x81042b918: .long 0x8 (gdb) info reg r0 0x810563d10 34633825552 r1 0x3fffffffffffd980 4611686018427378048 r2 0x0 0 r3 0x810043060 34628448352 r4 0x1 1 r5 0x1 1 r6 0x8103d9490 34632209552 r7 0x0 0 r8 0x29 41 r9 0x4e 78 r10 0x3fffffffffffc8f8 4611686018427373816 r11 0x81056c28c 34633859724 r12 0x81042b900 34632546560 r13 0x81005f020 34628562976 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x0 0 r19 0x0 0 r20 0x0 0 r21 0x0 0 r22 0x0 0 r23 0x0 0 r24 0x0 0 r25 0x0 0 r26 0x0 0 r27 0x0 0 r28 0x1 1 r29 0x3fffffffffffdb78 4611686018427378552 r30 0x3fffffffffffdb88 4611686018427378568 r31 0x3fffffffffffd980 4611686018427378048 pc 0x81042b900 0x81042b900 msr cr 0x28000802 671090690 lr 0x10000dcc 0x10000dcc ctr 0x81042b900 34632546560 xer 0x0 0 fpscr 0x0 0 vscr vrsave And the following shows how r12 and ctr were filled in by code that expected r2 to be correct: (gdb) x/32i 0x100007c0 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 . . . Overall: r2 seem to be mishandled in the exception handling. Note on the gdb use: The above devel/gdb activity was executed from a devel/powerpc64-xtoolchain-gcc built world that was based on WITHOUT_LLVM_LIBUNWIND=3D and and my patched libgcc_s material. This means it suffered from mismatches with the clang/libunwind world (that I chroot to): QUOTE warning: .dynamic section for "/usr/lib/libc++.so.1" is not at the = expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libcxxrt.so.1" is not at the = expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libm.so.5" is not at the expected = address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libc.so.7" is not at the expected = address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the = expected address (wrong library or version mismatch?) warning: .dynamic section for "/libexec/ld-elf.so.1" is not at the = expected address (wrong library or version mismatch?) END QUOTE But any thrown exceptions the gdb may have used worked in my patched WITHOUT_LLVM_LIBUNWIND=3D environment. This gdb is not limited to dwarf-2. The material from the a.out is not misinterpreted even if library code details might be. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Mar 13 03:24:41 2019 Return-Path: Delivered-To: freebsd-ppc@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 18ECB154847F for ; Wed, 13 Mar 2019 03:24:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-20.consmr.mail.ne1.yahoo.com (sonic304-20.consmr.mail.ne1.yahoo.com [66.163.191.146]) (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 21A47927DB for ; Wed, 13 Mar 2019 03:24:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: sN8m3aMVM1mmJD19pZxn.KIqiVw8VlfjDxCBPFxqrO2b__SO6SE3xvGXKgYvOgM HGoZlGRGzlHIyHTYZo2oH44ScQ3vf1YferLXERBVf4cUGUN33fow_hoRVMuwDei1OjPXkjOgqFZp 7.SzIsk6ZAlCm.bvx5ST72yRl1dLjhkAGjhry1ZO2GOFzZ3dgFsopa.RuasMxLsi4866H.pFVMe0 79xQpSWuytH1xIRkG.m15oC99HZIJ2C2LCPwonLmubLzsurmtDkF_MQ20NnFjBeeVfuc4FxJlWVU i11XqzFzczWJZDIA1AZNboYvBjo996Rcwu4jwcZ9QUMBCZcGBK_eMDdOg20gvm7B08uyIwZSeVK_ iVWWDuBV8urst2Y1I__OCoDFm6VLLNOUH6YOxa1AikObBE1_2_MV07CCsCaJQGQ8s7rruu1pFwms 6NvyTwt0Fdo3Nn7q3tMTObzV7NCvNh4XC4kNHU4CVo6tEOq3oCJh8BvTg4YQr.p1QyO03FZ_RTEO lXfqomuklNG9_WA3J.R5t7kunNWw7REtfr29elUiXdHtQtBuGilUWFFGik8rUYV0PeEu3rCQx5MR i5v6wa.lkZx3D2TwlpkIoO5w9Ls5vILXGsbXjd2tTExY0vsOdvOIc2.TvmR0qr.r8qItGP9ufbpo Gqb2orvUEAL8DvuYh0SOiTjysqLDBmGbZAH2h4nKaFlwJjqODSQSFSrEqhAimsMDYPqzhPr9U27. tX7Li3ZZHLHmdQXUrkywpVeRBbX.lS5qriSHZdFZFeF2AElHpO35lBiu4jT2IWlFoQme80fnqS63 OKcQlF8hpqyqFVxUPkBstfiw4ZIrM1BQPVYXfPX9CVmROI_hzM78KaR8CZTCBDDEoUq7HfykGl85 z6ibgsdBLO7sZJEK.UGd0fJhxQ948lJ11igfn2ULv_lIWuLzgCVUzRDsxSZRkL8fyCS3AcfJRmuY 5vDSZiXprv.epsQXtOk_XwpONcHWcnl3GkpFJNolMlSrKPn1pbai6EHljlDx0xkLiZvlkR3gXi_6 aE4AKKpI.Q_Rr3D_VAEdOPoT4btLSeu_e8JNOIvvMqOl8NJw9oeZq1xEgvioB2PNgMjb3V8Tv Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Wed, 13 Mar 2019 03:24:37 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp423.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3ab372a0c178cdb6562a2fb532b534d9; Wed, 13 Mar 2019 03:24:32 +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 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r345044: WITH_LLVM_LIBUNWIND= based buildworld leads to thrown C++ exceptions segmentation faulting Date: Tue, 12 Mar 2019 20:24:30 -0700 References: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> <3B37B7B0-DCB0-4984-AABD-4C3448DA7D56@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Toolchain In-Reply-To: <3B37B7B0-DCB0-4984-AABD-4C3448DA7D56@yahoo.com> Message-Id: <92CBCDF0-C870-49A8-8A00-868C7BACF38A@yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 21A47927DB X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.66 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.976,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.49)[ip: (5.31), ipnet: 66.163.184.0/21(1.23), asn: 36646(0.98), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.82)[0.818,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.88)[0.884,0]; RCVD_IN_DNSWL_NONE(0.00)[146.191.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 03:24:41 -0000 [Explicitly setting r2 to its expected value in gdb does let the program complete without failing.] > On 2019-Mar-12, at 16:34, Mark Millard wrote: >=20 > [The unoptimized code is more revealing so I switch to > presenting it and what it lead me to: more detail on > r2 being mishandled.] >=20 >> On 2019-Mar-12, at 14:05, Mark Millard wrote: >>=20 >> [I got some libunwind debug output from the a.out run. This >> and a disassembly of main suggest an instruction pointer >> address is too large by 0x4 for jumping to the code that >> would call __cxa_begin_catch .] >>=20 >>> On 2019-Mar-12, at 12:20, Mark Millard wrote: >>>=20 >>> [I sometimes experiment with building powerpc64 (and 32-bit) via >>> more modern toolchains, here a amd64->powerpc64 cross build via >>> system-clang (so 8.0.0).] >>>=20 >>> buildworld with WITH_LLVM_LIBUNWIND=3D completes for powerpc64 >>> (but not 32-bit powerpc). However, for a system installed >>> from such for pwoerpc64, the following program (for example) >>> gets a segmentation fault: >>>=20 >>> # more ~/c_tests/exception_test.cpp=20 >>> #include >>>=20 >>> int main(void) >>> { >>> try { throw std::exception(); } >>> catch (std::exception& e) {} >>> return 0; >>> } >>>=20 >>> (Note: the same a.out works under a WITHOUT_LLVM_LIBUNWIND=3D >>> environment, that was patched for DW_CFA_remember_state and >>> DW_CFA_restore_state handling, with the system built via >>> devel/powerpc64-xtoolchain-gcc related materials. So the >>> failure is on the system library does of things for the >>> WITH_LLVM_LIBUNWIND=3D context.) >>>=20 >>> Unfortunately: >>>=20 >>> A) devel/gdb makes extensive use of thrown C++ exceptions >>> and so does not work for a powerpc64 system based on >>> WITH_LLVM_LIBUNWIND=3D . >>>=20 >>> B) The world built is not using dwarf-2 so /usr/libexec/gdb >>> is not handy/useful. >>>=20 >>> C) CFLAGS+=3D-gdwarf-2 leads to system-clang having an Abort >>> trap during buildworld's compile of gcrt1.s . (Reference >>> material later, below.) >>>=20 >>> D) lldb crashes in llvm_unreachable in >>> lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() >>> on powerpc64. (Reference material later, below.) >>>=20 >>> So I've not managed to check the backtrace for the >>> segmentation fault in the short example. >>>=20 >>>=20 >>>=20 >>> For reference . . . >>>=20 >>>=20 >>> For (C) ( -gdwarf-2 use ): >>>=20 >>> QUOTES >>> (gdb) bt >>> #0 thr_kill () at thr_kill.S:3 >>> #1 0x000000000474afcf in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 >>> #2 0x00000000046cd386 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 >>> #3 0x00000000047394ba in __assert (func=3D, = file=3D, line=3D, failedexpr=3D) at /usr/src/lib/libc/gen/assert.c:51 >>> #4 0x000000000429aa9f in resetRootFile () at = /usr/src/contrib/llvm/include/llvm/MC/MCDwarf.h:316 >>> #5 parseDirectiveFile () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:3377 >>> #6 parseStatement () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:2023 >>> #7 0x000000000428cc12 in Run () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:884 >>> #8 0x000000000163c649 in ExecuteAssembler () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:503 >>> #9 cc1as_main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:589 >>> #10 0x0000000001643d10 in ExecuteCC1Tool () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:312 >>> #11 main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 >>>=20 >>> void resetRootFile() { >>> assert(Header.MCDwarfFiles.empty()); >>> Header.RootFile.Name.clear(); >>> Header.resetMD5Usage(); >>> Header.HasSource =3D false; >>> } >>>=20 >>> --- lib/csu__L --- >>> cc: error: unable to execute command: Abort trap (core dumped) >>> cc: error: clang integrated assembler command failed due to signal = (use -v to see invocation) >>> FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on = LLVM 8.0.0) >>> Target: powerpc64-unknown-freebsd13.0 >>> Thread model: posix >>> InstalledDir: /usr/bin >>> cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. >>> cc: note: diagnostic msg: Error generating preprocessed source(s) - = no preprocessable inputs. >>> *** [gcrt1.o] Error code 254 >>>=20 >>> make[5]: stopped in /usr/src/lib/csu/powerpc64 >>> .ERROR_TARGET=3D'gcrt1.o' >>> = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/gcrt1.o.meta' >>> .MAKE.LEVEL=3D'5' >>> MAKEFILE=3D'' >>> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >>> _ERROR_CMD=3D'cc -gdwarf-2 -target powerpc64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe = -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -mlongcall = -DCRT_IRELOC_SUPPRESS -std=3Dgnu99 -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls = -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o gcrt1.o gcrt1.s;' >>> .CURDIR=3D'/usr/src/lib/csu/powerpc64' >>> .MAKE=3D'make' >>> = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/lib/csu/powerpc64' >>> .TARGETS=3D'all' >>> = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/tmp' >>> LD_LIBRARY_PATH=3D'' >>> MACHINE=3D'powerpc' >>> MACHINE_ARCH=3D'powerpc64' >>> MAKEOBJDIRPREFIX=3D'' >>> MAKESYSPATH=3D'/usr/src/share/mk' >>> MAKE_VERSION=3D'20181221' >>> = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/p= owerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lega= cy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_alt= binutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin= :/bin:/usr/sbin:/usr/bin' >>> SRCTOP=3D'/usr/src' >>> = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64' >>> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/csu/powerpc64/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/csu/powerpc64/../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/csu/powerpc64/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' >>> .PATH=3D'. /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common' >>> 1 error >>> END QUOTES >>>=20 >>>=20 >>> For (D) (lldb): >>>=20 >>> QUOTES >>> CPU not supported >>> UNREACHABLE executed at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192! >>> Abort trap (core dumped) >>>=20 >>> (gdb) bt >>> #0 0x0000000813715208 in .__sys_thr_kill () at thr_kill.S:3 >>> #1 0x00000008137147cc in __raise (s=3D) at = /usr/src/lib/libc/gen/raise.c:52 >>> #2 0x000000081366b5d8 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 >>> #3 0x0000000011df6fb8 in llvm::llvm_unreachable_internal () at = /usr/src/contrib/llvm/lib/Support/ErrorHandling.cpp:222 >>> #4 0x00000000103aaaf8 in FreeBSDThread::GetRegisterContext () at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192 >>> #5 0x00000000105807d4 in lldb_private::Thread::SetupForResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Thread.cpp:613 >>> #6 0x0000000010571bc8 in lldb_private::ThreadList::WillResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/ThreadList.cpp:541 >>> #7 0x00000000105da23c in lldb_private::Process::PrivateResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Process.cpp:3281 >>> #8 0x00000000105a00c8 in lldb_private::Target::Launch () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Target.cpp:2922 >>> #9 0x000000001073f550 in CommandObjectProcessLaunch::DoExecute () = at = /usr/src/contrib/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:= 221 >>> #10 0x00000000106c36c4 in lldb_private::CommandObjectParsed::Execute = () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:975 >>> #11 0x00000000106d8b44 in = lldb_private::CommandInterpreter::HandleCommand () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :1761 >>> #12 0x00000000106da0a0 in = lldb_private::CommandInterpreter::IOHandlerInputComplete () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :2801 >>> #13 0x00000000107c0a08 in lldb_private::IOHandlerEditline::Run () at = /usr/src/contrib/llvm/tools/lldb/source/Core/IOHandler.cpp:558 >>> #14 0x0000000010346e5c in lldb_private::Debugger::ExecuteIOHandlers = () at /usr/src/contrib/llvm/tools/lldb/source/Core/Debugger.cpp:988 >>> #15 0x00000000106c8ddc in = lldb_private::CommandInterpreter::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :3003 >>> #16 0x000000001034feb4 in lldb::SBDebugger::RunCommandInterpreter () = at /usr/src/contrib/llvm/tools/lldb/source/API/SBDebugger.cpp:935 >>> #17 0x00000000101de878 in Driver::MainLoop () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:756 >>> #18 0x00000000101a0088 in main () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:936 >>>=20 >>> lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() { >>> if (!m_reg_context_sp) { >>> m_posix_thread =3D nullptr; >>>=20 >>> RegisterInfoInterface *reg_interface =3D nullptr; >>> const ArchSpec &target_arch =3D = GetProcess()->GetTarget().GetArchitecture(); >>>=20 >>> switch (target_arch.GetMachine()) { >>> case llvm::Triple::aarch64: >>> reg_interface =3D new RegisterInfoPOSIX_arm64(target_arch); >>> break; >>> case llvm::Triple::arm: >>> reg_interface =3D new RegisterInfoPOSIX_arm(target_arch); >>> break; >>> case llvm::Triple::ppc: >>> #ifndef __powerpc64__ >>> reg_interface =3D new = RegisterContextFreeBSD_powerpc32(target_arch); >>> break; >>> #endif >>> case llvm::Triple::ppc64: >>> reg_interface =3D new = RegisterContextFreeBSD_powerpc64(target_arch); >>> break; >>> case llvm::Triple::mips64: >>> reg_interface =3D new RegisterContextFreeBSD_mips64(target_arch); >>> break; >>> case llvm::Triple::x86: >>> reg_interface =3D new RegisterContextFreeBSD_i386(target_arch); >>> break; >>> case llvm::Triple::x86_64: >>> reg_interface =3D new RegisterContextFreeBSD_x86_64(target_arch); >>> break; >>> default: >>> llvm_unreachable("CPU not supported"); >>> } >>> END QUOTES. >>=20 >>=20 >>=20 >> I ran into libunwind having LIBUNWIND_PRINT_UNWINDING and >> LIBUNWIND_PRINT_APIS so I can report for the segmentation >> fault: >>=20 >> # export LIBUNWIND_PRINT_UNWINDING=3D"" >> # export LIBUNWIND_PRINT_APIS=3D"" >> # ./a.out >> . . . >=20 > Using unoptimized code instead: >=20 > # c++ -g exception_test.cpp > libunwind: __register_frame_info(0x137d6610, 0x13ae3150) > libunwind: __register_frame_info(0x137d6610, 0x13ae3150) > libunwind: __deregister_frame_info(0x137d6610) > libunwind: __deregister_frame_info(0x137d6610) > # ./a.out > libunwind: _Unwind_RaiseException(ex_obj=3D0x810043060) > libunwind: unw_init_local(cursor=3D0x3fffffffffffcb48, = context=3D0x3fffffffffffd0e0) > libunwind: unw_step(cursor=3D0x3fffffffffffcb48) > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffd830) > libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffd628, bufLen=3D512) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffd618) > libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x81019d954, = start_ip=3D0x81019d860, func=3D.anonymous., lsda=3D0x0, personality=3D0x0 > libunwind: unw_step(cursor=3D0x3fffffffffffcb48) > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffd830) > libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffd628, bufLen=3D512) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffd618) > libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x10000dac, = start_ip=3D0x10000d64, func=3D.anonymous., lsda=3D0x10000fe0, = personality=3D0x8101b5360 > libunwind: unwind_phase1(ex_ojb=3D0x810043060): calling personality = function 0x8101b5360 > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc950) > libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb48)= =3D> 0x10000fe0 > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc890) > libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb48) =3D> = 0x10000d64 > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffc8c8) > libunwind: _Unwind_GetIP(context=3D0x3fffffffffffcb48) =3D> 0x10000dac > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc880) > libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb48) =3D> = 0x10000d64 > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffd828) > libunwind: unwind_phase1(ex_ojb=3D0x810043060): _URC_HANDLER_FOUND > libunwind: unw_init_local(cursor=3D0x3fffffffffffcb48, = context=3D0x3fffffffffffd0e0) > libunwind: unwind_phase2(ex_ojb=3D0x810043060) > libunwind: unw_step(cursor=3D0x3fffffffffffcb48) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffca10) > libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffc810, bufLen=3D512) > libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x81019d860, = func=3D.anonymous., sp=3D0x3fffffffffffd8e0, lsda=3D0x0, personality=3D0x0= > libunwind: unw_step(cursor=3D0x3fffffffffffcb48) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffca10) > libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffc810, bufLen=3D512) > libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x10000d64, = func=3D.anonymous., sp=3D0x3fffffffffffd980, lsda=3D0x10000fe0, = personality=3D0x8101b5360 > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc610) > libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb48)= =3D> 0x10000fe0 > libunwind: _Unwind_SetIP(context=3D0x3fffffffffffcb48, = value=3D0x10000db4) > libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = value=3D0x10000db4) > libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb48, reg=3D3, = value=3D0x810043060) > libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D3, = value=3D0x810043060) > libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb48, reg=3D4, = value=3D0x1) > libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D4, = value=3D0x1) > libunwind: unwind_phase2(ex_ojb=3D0x810043060): _URC_INSTALL_CONTEXT > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffc810) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) > libunwind: unwind_phase2(ex_ojb=3D0x810043060): re-entering user code = with ip=3D0x10000db4, sp=3D0x3fffffffffffd980 > libunwind: unw_resume(cursor=3D0x3fffffffffffcb48) > Segmentation fault (core dumped) >=20 > The below shows that the 0x10000db4 in this case seems right --and > also that the code sequence does not set r2. Apparently the > throw handling was supposed to set it so the optimized code > skips setting it. (Later below it seems r2 should have been > set by something but was not correctly set.) >=20 > (gdb) disass main > Dump of assembler code for function main(): > 0x0000000010000d64 <+0>: mflr r0 > 0x0000000010000d68 <+4>: std r31,-8(r1) > 0x0000000010000d6c <+8>: std r0,16(r1) > 0x0000000010000d70 <+12>: stdu r1,-160(r1) > 0x0000000010000d74 <+16>: mr r31,r1 > 0x0000000010000d78 <+20>: li r3,0 > 0x0000000010000d7c <+24>: stw r3,148(r31) > 0x0000000010000d80 <+28>: li r3,8 > 0x0000000010000d84 <+32>: bl 0x100007a0 = <00000018.plt_call.__cxa_allocate_exception@@CXXABI_1.3> > 0x0000000010000d88 <+36>: ld r2,40(r1) > 0x0000000010000d8c <+40>: std r3,112(r31) > 0x0000000010000d90 <+44>: bl 0x10000e00 = > 0x0000000010000d94 <+48>: nop > 0x0000000010000d98 <+52>: ld r4,-32728(r2) > 0x0000000010000d9c <+56>: nop > 0x0000000010000da0 <+60>: ld r5,-32720(r2) > 0x0000000010000da4 <+64>: ld r3,112(r31) > 0x0000000010000da8 <+68>: bl 0x10000800 = <00000018.plt_call.__cxa_throw@@CXXABI_1.3> > 0x0000000010000dac <+72>: ld r2,40(r1) > 0x0000000010000db0 <+76>: b 0x10000df4 > 0x0000000010000db4 <+80>: mr r5,r4 > 0x0000000010000db8 <+84>: std r3,136(r31) > 0x0000000010000dbc <+88>: stw r5,132(r31) > 0x0000000010000dc0 <+92>: b 0x10000dc4 > 0x0000000010000dc4 <+96>: ld r3,136(r31) > 0x0000000010000dc8 <+100>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> > 0x0000000010000dcc <+104>: ld r2,40(r1) > 0x0000000010000dd0 <+108>: std r3,120(r31) > 0x0000000010000dd4 <+112>: bl 0x100007e0 = <00000018.plt_call.__cxa_end_catch@@CXXABI_1.3> > 0x0000000010000dd8 <+116>: ld r2,40(r1) > 0x0000000010000ddc <+120>: li r3,0 > 0x0000000010000de0 <+124>: addi r1,r1,160 > 0x0000000010000de4 <+128>: ld r0,16(r1) > 0x0000000010000de8 <+132>: ld r31,-8(r1) > 0x0000000010000dec <+136>: mtlr r0 > 0x0000000010000df0 <+140>: blr > 0x0000000010000df4 <+144>: .long 0x0 > 0x0000000010000df8 <+148>: .long 0x0 > 0x0000000010000dfc <+152>: .long 0x0 > End of assembler dump. >=20 > Notably lr seems to be: 0x10000dcc which > is just after: >=20 > bl 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> >=20 > Note also the pc, r12, and ctr all having the failure > address: 0x81042b900 . >=20 > #0 0x000000081042b900 in ?? () from /lib/libc.so.7 > (gdb) x/32i 0x000000081042b8F0 > 0x81042b8f0 : .long 0x8 > 0x81042b8f4 : vmrglh v1,v30,v7 > 0x81042b8f8: .long 0x8 > 0x81042b8fc: vsubeuqm v1,v30,v7,v17 > =3D> 0x81042b900: .long 0x8 > 0x81042b904: vpmsumw v1,v30,v7 > 0x81042b908 <_citrus_bcs_skip_ws_len@got.plt>: .long 0x8 > 0x81042b90c <_citrus_bcs_skip_ws_len@got.plt+4>: .long 0x103e3c92 > 0x81042b910: .long 0x8 > 0x81042b914: .long 0x103e3c9b > 0x81042b918: .long 0x8 >=20 > (gdb) info reg > r0 0x810563d10 34633825552 > r1 0x3fffffffffffd980 4611686018427378048 > r2 0x0 0 > r3 0x810043060 34628448352 > r4 0x1 1 > r5 0x1 1 > r6 0x8103d9490 34632209552 > r7 0x0 0 > r8 0x29 41 > r9 0x4e 78 > r10 0x3fffffffffffc8f8 4611686018427373816 > r11 0x81056c28c 34633859724 > r12 0x81042b900 34632546560 > r13 0x81005f020 34628562976 > r14 0x0 0 > r15 0x0 0 > r16 0x0 0 > r17 0x0 0 > r18 0x0 0 > r19 0x0 0 > r20 0x0 0 > r21 0x0 0 > r22 0x0 0 > r23 0x0 0 > r24 0x0 0 > r25 0x0 0 > r26 0x0 0 > r27 0x0 0 > r28 0x1 1 > r29 0x3fffffffffffdb78 4611686018427378552 > r30 0x3fffffffffffdb88 4611686018427378568 > r31 0x3fffffffffffd980 4611686018427378048 > pc 0x81042b900 0x81042b900 > msr > cr 0x28000802 671090690 > lr 0x10000dcc 0x10000dcc > ctr 0x81042b900 34632546560 > xer 0x0 0 > fpscr 0x0 0 > vscr > vrsave >=20 > And the following shows how r12 and ctr were filled in by > code that expected r2 to be correct: >=20 > (gdb) x/32i 0x100007c0 > 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) > 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) > 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 > 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) > 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) > 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr > 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 > 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 > . . . >=20 > Overall: r2 seem to be mishandled in the exception handling. Just before: 0x0000000010000dc8 <+100>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> (gdb) set $r2=3D0x10019300 (gdb) c Continuing. Program exited normally. r2 has the wrong value and needs to have been set by: ld r2,40(r1) (expressed as an additional instruction in teh prelude to bl 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>) That shows how I got the 0x10019300 value as well: 40(r1) lookup. This makes the optimized code interesting because it had the "ld r2,40(r1)" but it was skipped by that code being started at 0x0000000010000dac . 0x0000000010000da8 <+68>: ld r2,40(r1) 0x0000000010000dac <+72>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> (An earlier message of this sequence has more detail for the optimized code.) > Note on the gdb use: >=20 > The above devel/gdb activity was executed from a > devel/powerpc64-xtoolchain-gcc built world that was based on > WITHOUT_LLVM_LIBUNWIND=3D and and my patched libgcc_s material. > This means it suffered from mismatches with the clang/libunwind > world (that I chroot to): >=20 > QUOTE > warning: .dynamic section for "/usr/lib/libc++.so.1" is not at the = expected address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/lib/libcxxrt.so.1" is not at the = expected address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/lib/libm.so.5" is not at the expected = address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/lib/libc.so.7" is not at the expected = address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the = expected address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/libexec/ld-elf.so.1" is not at the = expected address (wrong library or version mismatch?) > END QUOTE >=20 > But any thrown exceptions the gdb may have used worked in my > patched WITHOUT_LLVM_LIBUNWIND=3D environment. This gdb is not > limited to dwarf-2. >=20 > The material from the a.out is not misinterpreted even if > library code details might be. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Mar 13 05:08:33 2019 Return-Path: Delivered-To: freebsd-ppc@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 8B4DD1525408 for ; Wed, 13 Mar 2019 05:08:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 55F6F95A84 for ; Wed, 13 Mar 2019 05:08:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oMKI.N4VM1m80RvEaSPy4EcyzDfRQ4V.3ktvKOKzbRCco6OjEJdzrtIb3gvpKUz 8DLHgDQNaCpbjiZ0YOyKfuBQDykt9Hh723GNGHcB4aa00rYOcXUQJTjKHKjraFYpGf8Yeta7kePt ciGtyXoXU7ZSKiuiTsmfkADPmrbRteW.BDpNpEOHe3XN6cY2SHPRQMRcQYBaq2ad0mp049XaruwZ USIod2jOiHiR_ryPInTOplP1byyvXFy62S.LluOdEe9EGHKel28ABwZ9ek.P1KaQZPLfnW2Cs4Hp IYia_Mp6Yb.fnUVRI6MPoTYXABIaib9PGJRr.Yi292xBJG4D4P.9.LI_4RvsOpv601PVdTNbWyhq lWrQZQlw4kFxzcBmYQz9qvt_abUkO.UKI7Ao_AiM_moYUsP459EFAxaWooQ_2x.jXGu3sXXHKcPK wLRobQEMLL6n4SoLhibRS4dSpLiAZ.XavR4aYg02jbH9uY1A6j9pOzHMBHVbb0VQ8JGIyWb8KvOe JbyU7iaqWKNxJfq4SbYzjee.CMB6Dw_Q_DffuaMl033k4NMx_CSR.7R8NM2dfylo1l4stLBuYJTy yoCCLixW2HgXLnyPXNuP93tSzGOTX0KMvBfOiar_lOmI5Jg0E.eUIRkdmq1t7vl.6gq1EUvr5kRN .KyM0sMjsP757dBJEA2NZlEqwvOKadCih20MsyARvXhjOS.aanolfhNJV.GfU_6vfuYVsBM4cYtb I118qfaIvehJSxhsxb5iDm0161Ti9DlEuqLfFIoCmj_7Njjua95DgY7B7wCRZH_cyz3aJjVY0RgQ DdJb3xaP.oaUDcjpGyvOpQyCpMel2QJTUUUA7vaP893jLg0L_BL63fGZRlD6qZIkQWyUFHyywK5J sEzYb44BTXbCAOFq1U33x5EBKQBB0X3ncOXpLlElY3xZiRYy3yuQlOJpKmvx8rseABVj2Sx5Wsle .WytxpQX9nj.b30uZ8Fr0hpI.eJ7o1E17xyHzoGGnvYp9X1khwUbHf6XXJyYB44GmqMQmCz6cn7R pgJ2gIE1NhKU7JzAHzzfPHc1c7u0VJ4aT7F5W74wQxq5s5SG8HSvD0bavbTjU2EIWMBt0o59Qc9P 0Gb6K_0op Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 Mar 2019 05:08:25 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp417.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6c98a8c6421053bf4a99aad6b4df2756; Wed, 13 Mar 2019 05:08:21 +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 12.2 \(3445.102.3\)) Subject: llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code Message-Id: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> Date: Tue, 12 Mar 2019 22:08:20 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 55F6F95A84 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.53 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.48)[-0.476,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.84)[0.836,0]; NEURAL_HAM_LONG(-0.87)[-0.870,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.49)[ip: (0.77), ipnet: 98.137.64.0/21(0.98), asn: 36647(0.79), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.69.137.98.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 05:08:33 -0000 I have submitted: https://bugs.llvm.org//show_bug.cgi?id=3D41050 for the clang 8 code generation problem of no code for setting r2 appropriately before the: bl . . . <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> in unoptimized code ( no -O ). For the -O2 code: ld r2,40(r1) is present but is being skipped by the libunwind return to the code: it returns to the just-following bl instruction (like above) instead. In both cases: (gdb) x/32i 0x100007c0 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: std = r2,40(r1) 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 . . . with an inappropriate r2 value leads to jumping to inappropriate places. The example source code was: #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } Note: This is from investigations of head -r345044 using WITH_LLVM_LIBUNWIND=3D on powerpc64. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Mar 13 19:06:11 2019 Return-Path: Delivered-To: freebsd-ppc@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 E8215153E4B2; Wed, 13 Mar 2019 19:06:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4CD4A6A963; Wed, 13 Mar 2019 19:06:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2DJ61oF003064 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 21:06:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2DJ61oF003064 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2DJ5wrI003063; Wed, 13 Mar 2019 21:05:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Mar 2019 21:05:58 +0200 From: Konstantin Belousov To: Bruce Evans Cc: Mark Millard , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) Message-ID: <20190313190558.GB2492@kib.kiev.ua> References: <20190302225513.W3408@besplex.bde.org> <20190302142521.GE68879@kib.kiev.ua> <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190305223415.U1563@besplex.bde.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 19:06:11 -0000 On Wed, Mar 06, 2019 at 12:19:38AM +1100, Bruce Evans wrote: > On Tue, 5 Mar 2019, Bruce Evans wrote: > > > On Mon, 4 Mar 2019, Konstantin Belousov wrote: > > >* [... shift for bogus TSC-low timecounter] > >> I suspect that the shift of 1 (at least) hides cross-socket inaccuracy. > >> Otherwise, I think, some multi-socket machines would start showing the > >> detectable backward-counting bintime(). At the frequencies at 4GHz and > >> above (Intel has 5Ghz part numbers) I do not think that stability of > >> 100MHz crystall and on-board traces is enough to avoid that. > > > > I think it is just a kludge that reduced the problem before it was fixed > > properly using fences. > > > > Cross-socket latency is over 100 cycles according to jhb's tscskew > > benchmark: on Haswell 4x2: > > > > CPU | TSC skew (min/avg/max/stddev) > > ----+------------------------------ > > 0 | 0 0 0 0.000 > > 1 | 24 49 84 14.353 > > 2 | 164 243 308 47.811 > > 3 | 164 238 312 47.242 > > 4 | 168 242 332 49.593 > > 5 | 168 243 324 48.722 > > 6 | 172 242 320 52.596 > > 7 | 172 240 316 53.014 > > > > freefall is similar. Latency is apparently measured relative to CPU 0. > > It is much lower to CPU 1 since that is on the same core. > > > > I played with this program a lot 3 and a half years ago, but forgot > > mist of what I learned :-(. I tried different fencing in it. This > > seems to make little difference when the program is rerun. With the > > default TESTS = 1024, the min skew sometimes goes negative on freefall, > > but with TESTS = 1024000 that doesn't happen. This is the opposite > > of what I would expect. freefall has load average about 1. > > I understand this program again. First, its name is actually tscdrift. > I tested the 2015 version, and this version is still in > /usr/src/tools/tools/tscdrift/tscdrift.c, with no changes to except to > the copyright (rgrimes wouldn't like this) and to $FreeBSD$. > > The program doesn't actually measure either TSC drift or TSC skew, except > indirectly. What it actually measures is the IPC (Inter-Process- > Communication) time for synchronizing the drift and skew measurments, > except bugs or intentional sloppiness in its synchronization also make it > give an indirect measurement of similar bugs or sloppiness in normal use. > > After changing TESTS from 1024 to 1024000, it shows large errors in the > negative direction, as expected from either large negative skew or program > bugs: this is on freefall: > > XX CPU | TSC skew (min/avg/max/stddev) > XX ----+------------------------------ > XX 0 | 0 0 0 0.000 > XX 1 | -6148 108 10232 46.871 > XX 2 | 114 209 95676 163.359 > XX 3 | 96 202 47835 101.250 > XX 4 | -2223 207 34017 117.257 > XX 5 | -2349 206 33837 106.259 > XX 6 | -2664 213 33579 96.048 > XX 7 | -2451 212 49242 126.428 Note that freefall is single-socket. My belief is that due to the construction of the RDTSC on Intels, it is impossible for the counter to become scew on single socket. All cores are fed from the same input signal, and most likely, even read the same uncore counter. The later is less likely because RDTSC latency is quite low, but there might be additional hw tricks. On the other hand, for multi-socket machines, I do not think there is anything except the external clock signal which would ensure that the counters stay in sync. I tried to imagine is there is any shared hardware on multi-socket Intel system which would give equal latency for accesses from different sockets, and it seems that there is no such hardware. Then it is trully impossible to observe the scew. It might be possible to measure round-trip time separately, and then subtract it from the measured scew. > > The negative "skews" occur because the server and the clients (1 client at > a time) read the TSC with uncontrolled timing after the server opens the > gate for this read (gate = 2). The IPC time is about 200 cycles to CPUs > on different cores. So when neither thread is preempted, the TSC on the > server is about 200 cycles in advance. Sometimes the server is preempted, > so it reads its TSC later than the client (a maximum of about 6148 cycles > later in this test). More often the client is preempted, since the IPC > time is march larger than the time between the server opening the gate and > the server reading its TSC. > > The server is also missing fencing for its TSC read, so this read may > appear to occur several cycles before opening the gate. This gives a > an error in the positive direction for the reported "skew" (the error > is actually in the positive direction for the reported IPC time). It > would be useful to measure this error by intentionally omitting fencing, > but currently it is just a small amount of noise on top of the noise from > preemption. > > After fixing the syncronization: > > XX CPU | TSC skew (min/avg/max/stddev) > XX ----+------------------------------ > XX 0 | 0 0 0 0.000 > XX 1 | 33 62 49161 57.652 > XX 2 | 108 169 33678 73.456 > XX 3 | 108 171 43053 119.256 > XX 4 | 141 169 41289 114.567 > XX 5 | 141 169 40035 112.755 > XX 6 | 132 186 147099 269.449 > XX 7 | 153 183 431526 436.689 > > Synchronization apparenly takes a long time, especially to other cores. > The minimum and avergae now gives the best-case IPC time very accurately. > The average is 20-30 cycles smaller than before, probably because I > fixed the fencing. The maximum and standard deviation are garbage noise > from preemption. Preemption should be disabled somehow. > > Large drifts and skews would show up as nonsense values for the minimum > IPC time. Small drifts would soon give large skews. To measure small > skews, change the CPU of the server to measure the minimum IPC time in > the opposite direction. > > Fixes: > > XX --- tscdrift.c 2015-07-10 06:22:36.505493000 +0000 > XX +++ w.c 2019-03-05 11:22:22.232341000 +0000 > XX @@ -32,6 +32,15 @@ > XX #include > XX #include > XX #include > XX +/* > XX + * XXX: atomic.h is not used. Instead we depend on x86 memory ordering and > XX + * do direct assignments to and comparisons of 'gate', and sometimes add > XX + * memory barriers. The correct atomic ops would do much the same with > XX + * clearer spelling. The 'lock' prefix is never needed and the barriers are > XX + * only to get program order so as to give acq or rel semantics for ether > XX + * the loads, the stores or for buggy unfenced rdtsc's. Fences also give > XX + * program order, so some of the explicit barriers are redundant. > XX + */ > XX #include > XX #include > XX #include > XX @@ -45,7 +54,7 @@ > XX > XX #define barrier() __asm __volatile("" ::: "memory") > XX > XX -#define TESTS 1024 > XX +#define TESTS 1024000 > XX > XX static volatile int gate; > XX static volatile uint64_t thread_tsc; > XX @@ -74,12 +83,12 @@ > XX gate = 1; > XX while (gate == 1) > XX cpu_spinwait(); > XX - barrier(); > XX > XX + barrier(); > XX __asm __volatile("lfence"); > XX thread_tsc = rdtsc(); > XX - > XX barrier(); > XX + > XX gate = 3; > XX while (gate == 3) > XX cpu_spinwait(); > > This is the client. The explicit barriers are confusing, and the blank > lines are in all the wrong places. All the accesses to 'gate' need > to be in program order. x86 memory ordering gives this automatically > at the hardware level. 'gate' being volatile gives it at the compiler > level. Both rdtsc() and storing the result to thread_tsc need to be > in program order. lfence() in cpufunc.h has a memory clobber which > gives the former, but we use a direct asm and need a barrier() before > it to do the same thing. Then we need another barrier() after the > assignment to thread_tsc so that the store for this is before the store > to 'gate' (I think gate being volatile doesn't give this). This also > keeps the rdtsc() in program order (the asm for rdtsc() doesn't have > a memory clobber. I haven't noticed care about this being taken > anywhere else). > > Summary: only style changes in this section. > > XX @@ -139,12 +148,13 @@ > XX for (j = 0; j < TESTS; j++) { > XX while (gate != 1) > XX cpu_spinwait(); > XX - gate = 2; > XX - barrier(); > > Move down opening the gate so that it not opened until after reading the > TSC on the server. > > XX > XX + barrier(); > XX + __asm __volatile("lfence"); > > Fencing is not critical here. Using an early TSC value just gives a larger > reported IPC time. The barrier is important for getting program order of > rdtsc(). > > XX tsc = rdtsc(); > XX - > XX barrier(); > > This barrier is still associated with the TSC read, and the blank like is > moved to reflect this. Here rdtsc() must occur in program order, but > storing to tsc can be after storing to 'gate'. The barrier gives ordering > for the store to tsc too. > > XX + > XX + gate = 2; > XX while (gate != 3) > XX cpu_spinwait(); > XX gate = 4; > > I tried some locked atomic ops on 'gate') and mfence instead of lfence > to try to speed up the IPC. Nothing helped. We noticed long ago that > fence instructions tend to be even slower that locked atomic ops for > mutexes, and jhb guessed that this might be because fence instructions > don't do so much to force out stores. I am not sure I follow. MFENCE is documented by wording that implies, without any doubts, that store buffers are flushed before the instruction is retired. It is not so obvious for SFENCE, which sounds like a real fence instead of full flush, at least for normal write-back memory where it is NOP as far as ISA is considered. It is known and documented in optimization manuals that locked operations are much more efficient, but locked ops are only documented to ensure ordering and not flush. So SFENCE is not suitable as our barrier. And, the second point, LFENCE there does not work as barrier for IPC. It only ensures that RDTSC is not started earlier than the previous instructions. No store buffer flushing is done. > > Similar IPC is needed for updating timecounters. This benchmark indicates > that after an update, the change usually won't be visible on other CPUs > for 100+ cycles. Since updates are rare, this isn't much of a problem. > > Similar IPC is needed for comparing timecounters across CPUs. Any activity > on different CPUs is incomparable without synchronization to establish an > ordering. Since fences give ordering relative to memory and timecounters > don't use anything except fences and memory order for the generation count > to establish their order, the synchronization for comparing timecounters > (or clock_gettime() at higher levels) must also use memory order. > > If the synchronization takes over 100 cycles, then smaller TSC skews don't > matter much (they never break monotonicity, and only show up time differences > varying by 100 or so cycles depending on which CPU measures the start and > end events). Small differences don't matter at all. Skews may be caused It should be more than 100 cycles for inter-socket IPC, but then genuine RDTSC scew can accumulate much larger than 100, which is my worry. > by the TSCs actually being out of sync, or hardware only syncing them on > average (hopefully with small jitter) or bugs like missing fences. Missing > fences don't matter much provided unserialized TSC reads aren't too far > in the past. E.g., if we had a guarantee of only 10 cycles in the past for > the TSC and 160 cycles for IPCs to other CPUs, then we could omit the fences. > But IPCs to the same core are 100 cycles faster so the margin is too close > for ommitting fences in all cases. I have no idea if RDTSC is allowed to execute before (in program order) earlier cache miss. If it is, then non-fenced RDTSC would easily give much larger error than IPC sync delay. > > Similarly for imperfect hardware. Hopefully its skew is in the +-1 cycle > range, but even +-10 isn't a problem if the IPC time is a bit larger than > 10 and even +-100 if the IPC time is a bit larger than 100. And the problem > scales nicely with the distance of the CPUs -- when they are further apart > so that hardware synchronization of their TSCs is more difficult, the IPC > time is large too. > > Hmm, that is only with physical IPCs. Since timecounters use physical > IPCs for everything, they can't work right with virtual synchronization. > Something like ntpd is needed to compare times across even small local > networks. It does virtual synchronization by compensating for delays. > > Bruce From owner-freebsd-ppc@freebsd.org Wed Mar 13 20:25:20 2019 Return-Path: Delivered-To: freebsd-ppc@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 048261540DF4 for ; Wed, 13 Mar 2019 20:25:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 B84BF6E7C9 for ; Wed, 13 Mar 2019 20:25:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ZIxdcuAVM1lpvAgC.IfMgIwEtoCInE36rN.16_uZzwK3ExhtbK1R39ftgmXFmRU BRmIjYjxj8tKmx_Y4lBvygjEW5dsqsRyCN9UZrDyD__Jkn4q5hnLWfr1OIFsYEJOXdYIWJOe7yPG 1siWx4qgvIWyodOaxj_HLzM7Z6FyuOgfblqk5w0w75w1M65D48ww82cO072yJYrn4KTUACJxs9cb 6koxTS4fMGFu_TBmprLsdcZZf4ySmIW64sEEqx2rBad997veGvP6nbFTWCUOJzCVAy3JwMOGdFob t_OLSW9.PO0FxLmS1dmnkNSEnjKb3ipLZK3UgkWTxoTFKA4JiUD0NsM_SJvJ3F_H1PYPfqvFCqfg RMy7UGIZCkDTCPrkW5UsL8US6r2fyHXPqNB2AHwX8UOJxac9zM1_iH6hDe99wZFwjwBs5MhXA08p nWyHoy5REGE7aMqyl6iRshEDXrvS0358lpRWID8bDQYMfiDvsUXHH5jTITql82b06d4SqLAvZz9F eni2AIJCYjyiCP1n29h5w9yvjcm8e4fND8ds0W32WidvKxj1GJ_LxafJb9zzJ3Nc2n5j31fCa2V0 VJctIegmYx09GhFOGuf8DbqyMfQVhrINHCsxdmahqIEUgdLEJmAR3c_3vWaIuoB6Z3FW0VYbF6Y8 Am3jnfvk20jdQhteXtQoEWYi23iilF_.GkDAgY3SBgXIhIXqSyGlBgBGuyxgl.l7X48U3mS2w37m gooGwp5UOX6TKvb9gY0i3dvHm4dEYRQD0xDOSO0xymwgyEXOYYrpLX5z0eGC7gfJ4xKxl5DoYUux Qyf2NMe1Rri1arvCxWg75VXpDfCq.jlyO2FrfLlYEAb3N1a8GvLQrhe0lHN5OYq9GAuObShX5W9j QIp8WXDysseCtPXOZJQjUTYldIRBzuT58.NPD9tUd30tU5EIzLH1IZdSGtpNdj4EKzcjbXrWrCs7 zI78SrMOuPHmCbL5fkuXRmJ462vJ3unJTuIVcSkhLaxGD4MnrVXLduNHzaoZGMKWA24zf1vRqTFW L0beqLY70NWRjc6wi7iasAr_kMX5wf_nmsqIDMjdbEXbEueQL7I52iPFKXRDS Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 Mar 2019 20:25:14 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e21aea6b1716ae0d89a03f93d0b5f824; Wed, 13 Mar 2019 20:15:05 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: C++11 Load/Store seq cst for powerpc64: which style does the FreeBSD ABI specify? Message-Id: <5B354F1C-AFDC-4306-857A-48AACB2D8492@yahoo.com> Date: Wed, 13 Mar 2019 13:15:04 -0700 To: FreeBSD PowerPC ML , freebsd-hackers Hackers X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: B84BF6E7C9 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.26 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.88)[ip: (2.70), ipnet: 98.137.64.0/21(0.98), asn: 36647(0.78), country: US(-0.07)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.82)[0.818,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_MEDIUM(0.37)[0.366,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.71)[0.708,0]; RCVD_IN_DNSWL_NONE(0.00)[147.69.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 20:25:20 -0000 According to: https://www.cl.cam.ac.uk/~pes20/cppppc/popl079-batty.pdf the following two alternatives do not interoperate correctly and so can not be mixed --and so the ABI needs to specify a choice of which to use so that code from various compilers and such can be mixed: (leading-sync style:) Load Seq Cst: sync; ld; cmp; bc; isync Store Seq Cst: sync; st vs. (the trailing-sync style:) Load Seq Cst: ld; sync Store Seq Cst: lwsync; st; sync Which is the powerpc64 FreeBSD ABI based on? Which is the 32-bit powerpc FreeBSD ABI based on? Is there a place to see the FreeBSD ABI specification of this for powerpc64 (and any related items)? If yes, where? Similarly for 32-bit powerpc. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Mar 13 21:47:45 2019 Return-Path: Delivered-To: freebsd-ppc@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 AE0C01542D56 for ; Wed, 13 Mar 2019 21:47:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-22.consmr.mail.ne1.yahoo.com (sonic303-22.consmr.mail.ne1.yahoo.com [66.163.188.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 30AEC71E01 for ; Wed, 13 Mar 2019 21:47:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: njhf4UMVM1konPYelGtCvG2CLqQbU2S165OHROnVAP9wg9HyjO51PkO4DNHPCzI 502D0uLj2YBDLZmRA64XBORhlQJw5Ghxwr2gLhSzvHb_gQL3VRU3lGMQiIEzuLn_SzfxW1etQXNW yIVlJDl6uWdELzd2j1r83.q0QvvLd0k3IwatDyRvhvfKaxv3NWSYMLzY8brSfeWi9amknabxYt.f RGKf2eIYU4WPvXQ9Zp3RrrndCSssCZuXEDikRFwPma0E1AzP1ygGxw3NMHG74HmWbiBSiRxI8XfW nsygbRMt93oqyoITKZ0peYNCB_YteN1CdB3tZ53QUMHJlNsn44fEG.75fxhlCmUBhukHw5sUVe7X _JdU.R40EsJEWnbMANXaBI.s6YQStGfcG21wFDdARTsnTmBDCB9NuDXE6hcaGzEZNeY7nfX4P3GS MTQUSARJBRzaxQ8V2vWeQP7xHTLITF1C7mir4XZmYAbw3Ut4lzODVY1Y9z.Pzs7dq_rAzOJ4InyK nz49Ir5bbQI8gaF11U.j.bD7Vvj_sQLOYdxmz92sPGA1qy0Bjpx0j2DETPgtBKnua48EOoBbaKV8 rkQRaUq1zn_4aKNYEdB9312tIFxpiBNOy9IXSlvpUXpqQ4TYjpVYDgyK.UJP5Q92qXFjpt9y6OkB L8bO8IjmtHdAQMC_5YTWp4GC.PTqBHnNdxmhpZdQkLk2HEev9Rm6f44IjBBwDqdAH6uMQg6qyE2O e9Wa_yQoPnuQYw4baEiRkTrTmNnmsVMBCllD9jusuuAVuauUqmngUd2oExmBBAx.Jk6RlrdQod_9 CMpr.e.2nSxYibH29sKLyN3WXrVm.lnB_kG3naWAED6TFUTv2rx9HtZLCEMnN5cyoDd0OL9SPElN x1AQ_ZdG8p7tw47KkugHcVuUM37Yq8n5uJ8bOAXyRyxvgEeriaJLIJWm8U.k7xbWCLodywlk.Ocf V18.t7SfBDwwkqwCF4.GMO3cYMxu8Fsl6GhT08K7PtDUon7iHZOPstheXTNtw9488k0CA3nw89Go rQse7h_WjkxY0YjmaBF5vrMYS38APcIPTD9Ef7md2lgHfeud1Crld._gOAuRU3OrfjvONKOi2t8M rvYiXNAM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Wed, 13 Mar 2019 21:47:38 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.113]) ([67.170.167.181]) by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 58284d86e6b91e2c7d115888f3682c37; Wed, 13 Mar 2019 21:47:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) From: Mark Millard In-Reply-To: <20190313190558.GB2492@kib.kiev.ua> Date: Wed, 13 Mar 2019 14:47:35 -0700 Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: 7bit Message-Id: <3C3486AE-DA3A-49DF-BAA5-139D4E99FADB@yahoo.com> References: <20190302225513.W3408@besplex.bde.org> <20190302142521.GE68879@kib.kiev.ua> <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> <20190313190558.GB2492@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 30AEC71E01 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.992,0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 21:47:45 -0000 On 2019-Mar-13, at 12:05, Konstantin Belousov wrote: >> . . . > I am not sure I follow. MFENCE is documented by wording that implies, > without any doubts, that store buffers are flushed before the > instruction is retired. It is not so obvious for SFENCE, which > sounds like a real fence instead of full flush, at least for normal > write-back memory where it is NOP as far as ISA is considered. > > It is known and documented in optimization manuals that locked > operations are much more efficient, but locked ops are only documented > to ensure ordering and not flush. So SFENCE is not suitable as our > barrier. What I've seen in papers for the C++ Load/Store Seq Cst mappings to processors is: For write-fencing style: Load Seq Cst: MOV from memory Store Seq Cst alternative 0: XCHG (which as an implicit lock prefix) Store Seq Cst alternative 1: MOV into memory; MFENCE For read-fencing style: Load Seq Cst alternative 0: LOCK XADD(0) Load Seq Cst alternative 1: MFENCE; MOV from memory Store Seq Cst: MOV into memory There is also: Seq Cst Fence: MFENCE I've never seen SFENCE (or LFENCE) suggested for any of the above. I would expect for C++ Seq Cst that the XCHG and the LOCK XADD(0) would need to flush store buffers in order for those alternatives to be valid for C++ Seq Cst. I've seen a reference to a "locked identity operation to the top of stack" as another form of locked style of Seq Cst fencing. (write-fencing and read-fencing can not be generally mixed for Seq Cst: they do not inter-operate.) > And, the second point, LFENCE there does not work as barrier for IPC. > It only ensures that RDTSC is not started earlier than the previous > instructions. No store buffer flushing is done. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Mar 14 02:14:16 2019 Return-Path: Delivered-To: freebsd-ppc@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 E7BEE1522793 for ; Thu, 14 Mar 2019 02:14:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-15.consmr.mail.bf2.yahoo.com (sonic311-15.consmr.mail.bf2.yahoo.com [74.6.131.125]) (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 91A8983D5E for ; Thu, 14 Mar 2019 02:14:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 4dS44lUVM1nTR.xMPGSveJUpmWHbQdDxTpx7zBxDe1wxv_8D0LRbT5.iDq5vv0S NOfWexcv0FEfA9bfBmI_gl2YjkrJSyewlbKmo1EFudwteJtdhgXTxSsb3fkDayBJGkrlduuW2br_ aBQwIyOTy2j21mforYkLBN5bs48fhNhNAeP9IpMnn7juJ0SoZEWcxO7e1N3ccltHbO..QCa2qLtN MMyyWPna27AsRCEavc8ptWMJELmTD478M78OrVwp5FhfE7F99nGKXsErhLqfUvNyCrFNZ2ma9mf9 Bpd6Ozc5SL7m2zqlO.Mh3NMZLdZzhZc767LgiQQrPeiGHDOqdwhVOEmxyqOmjrxN4sMdRiTHI.o2 SPcgQdPjozmmwpV4cIAnjk1mI6f2iE0mGfLK_1.MyQzEiHe.JDlSQUI97AqYH1wOZxuBLVqtnpwz SUyl.qUTMKCfksVkhA9.6wl5QxgP6cbpOcJiJs.T4qJGSN3uqByuECdstYLkxgjZPNj41_fIWwji IUoexNnChsNcK0HFtgWU9oWOG9elUcLmbw56I28db9k2krxVvXUfiV5orD8k4mzQrCfDGzzcI_BQ UEdXM7C5_YXFalvxxCEupAQNb_zOBtg5m_LC6uOIANVOyt4nXNTYp5t8x77xumukLBtqwS_y17rV Xuvs2t0dZ96K473uBGFmRF7fbG7zctNk5BHjp2dlfKs_wDeM8sYOrIYyxwN5HlVcb8FSTshFFTXK V4_Cvxm4GmIyA7LEhmNdrUwBzulXOl_wpA9aTipK7kNjZhONKlpiO9J4Ao6CJBbwwU6WpvSh2fNE NaB8Dlcm5chn5RcvTinE1.Xzr81N8784fqOQbfuk1yA6TkpCJtJPDW7yuUNpx7SfbfVzQmtsss_X 1fNBumiJcmuKfjIDjI3YlvmjXcO_ZNjbu74Kk5GnToV95L9qvUgcuu71sVGoZsUSbNRXZqNuowFB r5CogOd_zYmwQI8MPi0TDTXBRDa0okRhczGwR2u8O5nqo_3HsKQCQ1SVx9duct4vcp8bk.rg19Qy CEWWvPcannOtkDWLA105x6bYeBTIZpf9RxmZ_7r4DDfTMY1RIikKK2jOKAcnNC.Qh10jggnzaTYz VRb.XJwBO_xKDn8Q- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Thu, 14 Mar 2019 02:14:08 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp421.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f7ff231413ab9d9143064498881ad737; Thu, 14 Mar 2019 02:14:03 +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 12.2 \(3445.102.3\)) Subject: Re: llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code Date: Wed, 13 Mar 2019 19:14:01 -0700 References: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> To: FreeBSD Toolchain , FreeBSD PowerPC ML In-Reply-To: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> Message-Id: <2429D922-3214-4D40-9616-56BC0CB93A15@yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 91A8983D5E X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.39 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.93)[0.932,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.03)[ip: (2.65), ipnet: 74.6.128.0/21(1.43), asn: 26101(1.14), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.52)[0.523,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.41)[0.412,0]; RCVD_IN_DNSWL_NONE(0.00)[125.131.6.74.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 02:14:16 -0000 On 2019-Mar-12, at 22:08, Mark Millard wrote: > I have submitted: >=20 > https://bugs.llvm.org//show_bug.cgi?id=3D41050 >=20 > for the clang 8 code generation problem of > no code for setting r2 appropriately before > the: >=20 > bl . . . <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> >=20 > in unoptimized code ( no -O ). For the -O2 code: >=20 > ld r2,40(r1) >=20 > is present but is being skipped by the libunwind return > to the code: it returns to the just-following bl > instruction (like above) instead. >=20 > In both cases: >=20 > (gdb) x/32i 0x100007c0 > 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) > 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) > 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 > 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) > 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) > 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr > 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 > 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 > . . . >=20 > with an inappropriate r2 value leads to jumping to > inappropriate places. >=20 > The example source code was: >=20 > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} > return 0; > } >=20 >=20 >=20 > Note: >=20 > This is from investigations of head -r345044 using > WITH_LLVM_LIBUNWIND=3D on powerpc64. >=20 The discussion on https://bugs.llvm.org//show_bug.cgi?id=3D41050 indicates that the ld r2,??? to restore the value appropriate to the a.out code in my example should be happening via the library holding libunwind's code instead of the ld executing in the a.out code. So: thus far it is viewed as a libunwind issue instead of a clang one. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Mar 14 12:51:34 2019 Return-Path: Delivered-To: freebsd-ppc@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 D95D11541207; Thu, 14 Mar 2019 12:51:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 21B69763BB; Thu, 14 Mar 2019 12:51:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2ECpK3K056767 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 14:51:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2ECpK3K056767 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2ECpJwD056766; Thu, 14 Mar 2019 14:51:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 14:51:19 +0200 From: Konstantin Belousov To: Mark Millard Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) Message-ID: <20190314125119.GG2492@kib.kiev.ua> References: <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> <20190313190558.GB2492@kib.kiev.ua> <3C3486AE-DA3A-49DF-BAA5-139D4E99FADB@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C3486AE-DA3A-49DF-BAA5-139D4E99FADB@yahoo.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 12:51:34 -0000 On Wed, Mar 13, 2019 at 02:47:35PM -0700, Mark Millard wrote: > > > On 2019-Mar-13, at 12:05, Konstantin Belousov wrote: > > >> . . . > > I am not sure I follow. MFENCE is documented by wording that implies, > > without any doubts, that store buffers are flushed before the > > instruction is retired. It is not so obvious for SFENCE, which > > sounds like a real fence instead of full flush, at least for normal > > write-back memory where it is NOP as far as ISA is considered. > > > > It is known and documented in optimization manuals that locked > > operations are much more efficient, but locked ops are only documented > > to ensure ordering and not flush. So SFENCE is not suitable as our > > barrier. > > What I've seen in papers for the C++ Load/Store Seq Cst mappings to > processors is: > > For write-fencing style: > > Load Seq Cst: MOV from memory > Store Seq Cst alternative 0: XCHG (which as an implicit lock prefix) > Store Seq Cst alternative 1: MOV into memory; MFENCE > > For read-fencing style: > > Load Seq Cst alternative 0: LOCK XADD(0) > Load Seq Cst alternative 1: MFENCE; MOV from memory > Store Seq Cst: MOV into memory > > There is also: > > Seq Cst Fence: MFENCE > > I've never seen SFENCE (or LFENCE) suggested for any of the above. I do not discuss implementation of the C++11 memory model primitives. FWIW, FreeBSD atomic(9) uses more optimal variant of what you call read-fencing style on x86. I did not looked (or rather, do not remember what I saw) at the implementation of C1x memory model load_acq and store_rel in clang and gcc. My text above is about 1. ensuring that RDTSC is executed not earlier than the previous instructions in the program order, and 2. making stores from the server thread visible to the subordinate thread as soon as possible, so that the store buffer latency was not accounted for the RDTSC inter-core communication latency. > > I would expect for C++ Seq Cst that the XCHG and the LOCK XADD(0) > would need to flush store buffers in order for those alternatives > to be valid for C++ Seq Cst. > > I've seen a reference to a "locked identity operation to the top of > stack" as another form of locked style of Seq Cst fencing. > > (write-fencing and read-fencing can not be generally mixed for Seq > Cst: they do not inter-operate.) > > > And, the second point, LFENCE there does not work as barrier for IPC. > > It only ensures that RDTSC is not started earlier than the previous > > instructions. No store buffer flushing is done. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Mar 14 19:37:39 2019 Return-Path: Delivered-To: freebsd-ppc@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 9EFF7152916E; Thu, 14 Mar 2019 19:37:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 73DED8E426; Thu, 14 Mar 2019 19:37:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 1518D7E1BC4; Fri, 15 Mar 2019 06:37:28 +1100 (AEDT) Date: Fri, 15 Mar 2019 06:37:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Bruce Evans , Mark Millard , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) In-Reply-To: <20190313190558.GB2492@kib.kiev.ua> Message-ID: <20190315034923.S7485@besplex.bde.org> References: <20190302225513.W3408@besplex.bde.org> <20190302142521.GE68879@kib.kiev.ua> <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> <20190313190558.GB2492@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=UJetJGXy c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=JjY8lKhXyHmvJdNTt2IA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 73DED8E426 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-6.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[optusnet.com.au]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[optusnet.com.au]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: extmail.optusnet.com.au]; NEURAL_HAM_SHORT(-0.91)[-0.914,0]; IP_SCORE(-2.84)[ip: (-7.76), ipnet: 211.28.0.0/14(-3.57), asn: 4804(-2.84), country: AU(-0.04)]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; FREEMAIL_CC(0.00)[optusnet.com.au]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:37:39 -0000 On Wed, 13 Mar 2019, Konstantin Belousov wrote: > On Wed, Mar 06, 2019 at 12:19:38AM +1100, Bruce Evans wrote: >> [... tscdrift.c] >> I understand this program again. First, its name is actually tscdrift. >> I tested the 2015 version, and this version is still in >> /usr/src/tools/tools/tscdrift/tscdrift.c, with no changes to except to >> the copyright (rgrimes wouldn't like this) and to $FreeBSD$. >> >> The program doesn't actually measure either TSC drift or TSC skew, except >> indirectly. What it actually measures is the IPC (Inter-Process- >> Communication) time for synchronizing the drift and skew measurments, >> except bugs or intentional sloppiness in its synchronization also make it >> give an indirect measurement of similar bugs or sloppiness in normal use. >> >> After changing TESTS from 1024 to 1024000, it shows large errors in the >> negative direction, as expected from either large negative skew or program >> bugs: this is on freefall: >> >> XX CPU | TSC skew (min/avg/max/stddev) >> XX ----+------------------------------ >> XX 0 | 0 0 0 0.000 >> XX 1 | -6148 108 10232 46.871 >> XX 2 | 114 209 95676 163.359 >> XX 3 | 96 202 47835 101.250 >> XX 4 | -2223 207 34017 117.257 >> XX 5 | -2349 206 33837 106.259 >> XX 6 | -2664 213 33579 96.048 >> XX 7 | -2451 212 49242 126.428 > Note that freefall is single-socket. My belief is that due to the > construction of the RDTSC on Intels, it is impossible for the counter > to become scew on single socket. All cores are fed from the same > input signal, and most likely, even read the same uncore counter. > The later is less likely because RDTSC latency is quite low, but there > might be additional hw tricks. The large negative numbers show that even for single-socket, there are really large errors if times are compared without cross-CPU synchronization by the program. Initial skews in hardware are presumably smaller. If the hardware skew drifts then there is a large problem for the software to compensate. I think that is unlikely to be a problem. In a recent commit, mav@ wrote that some Skylake systems only return even values in rdtsc(), and some seem to have a much lower resolution of 180+ (?) cycles. 180 cycles might be from the skew being that much and the hardware refusing to return values closer than that, perhaps even on the same CPU. I already pointed out discarding bits as in TSC-low doesn't work to avoid comparing values that are too close. Rather the reverse. Compensating for skews needs as much accuracy as possible starting with measuring them. > On the other hand, for multi-socket machines, I do not think there is > anything except the external clock signal which would ensure that the > counters stay in sync. > > I tried to imagine is there is any shared hardware on multi-socket Intel > system which would give equal latency for accesses from different sockets, > and it seems that there is no such hardware. Then it is trully impossible > to observe the scew. Yes, it has relativistic problems too. A distance of 1 foot and a speed of 4GHz gives a skew of at least 4 cycles in "absolute" time. > It might be possible to measure round-trip time separately, and then > subtract it from the measured scew. The hardware can do that too, or at least provide some support. I think the "absolute" time must be determined by a distributed clock. Since the system is not usually under much acceleration, the relativistic problems are small. The clock has a knowable constant propagation speed. >> The negative "skews" occur because the server and the clients (1 client at >> a time) read the TSC with uncontrolled timing after the server opens the >> gate for this read (gate = 2). The IPC time is about 200 cycles to CPUs >> on different cores. So when neither thread is preempted, the TSC on the >> server is about 200 cycles in advance. Sometimes the server is preempted, >> so it reads its TSC later than the client (a maximum of about 6148 cycles >> later in this test). More often the client is preempted, since the IPC >> time is march larger than the time between the server opening the gate and >> the server reading its TSC. >> >> The server is also missing fencing for its TSC read, so this read may >> appear to occur several cycles before opening the gate. This gives a >> an error in the positive direction for the reported "skew" (the error >> is actually in the positive direction for the reported IPC time). It >> would be useful to measure this error by intentionally omitting fencing, >> but currently it is just a small amount of noise on top of the noise from >> preemption. >> >> After fixing the syncronization: >> >> XX CPU | TSC skew (min/avg/max/stddev) >> XX ----+------------------------------ >> XX 0 | 0 0 0 0.000 >> XX 1 | 33 62 49161 57.652 >> XX 2 | 108 169 33678 73.456 >> XX 3 | 108 171 43053 119.256 >> XX 4 | 141 169 41289 114.567 >> XX 5 | 141 169 40035 112.755 >> XX 6 | 132 186 147099 269.449 >> XX 7 | 153 183 431526 436.689 >> ... >> I tried some locked atomic ops on 'gate') and mfence instead of lfence >> to try to speed up the IPC. Nothing helped. We noticed long ago that >> fence instructions tend to be even slower that locked atomic ops for >> mutexes, and jhb guessed that this might be because fence instructions >> don't do so much to force out stores. > I am not sure I follow. MFENCE is documented by wording that implies, > without any doubts, that store buffers are flushed before the > instruction is retired. It is not so obvious for SFENCE, which > sounds like a real fence instead of full flush, at least for normal > write-back memory where it is NOP as far as ISA is considered. The program uses LFENCE partly because it is the documented method of serializing rdtsc on Intel CPUs. It only gives serialization on 1 CPU. The locking protocol gives serialization of memory accesses and rdtsc's across CPUs (after I fixed it). Only serialization of the rdtsc instructions -- their results may still be out of order if there is skew and the skew is larger than the IPC time. MFENCE is the documented method for serializing rdtsc on (some?) AMD CPUs, it is just slower on freefall's Xeon CPUs. SFENCE has little affect on freefall's Xeon CPUs. It apparently doesn't serialize rdtsc and is useless for the locking protocol. The locking protocol uses only load_acq, store_rel, fence_acq and fence_rel. These are disguised as simple C operations and compiler memory barriers. FENCE instructions apparently don't work for speeding up the store buffers. > It is known and documented in optimization manuals that locked > operations are much more efficient, but locked ops are only documented > to ensure ordering and not flush. So SFENCE is not suitable as our > barrier. I tried them too. What are they more efficient for? Is it just that they are local while fences are global? > And, the second point, LFENCE there does not work as barrier for IPC. > It only ensures that RDTSC is not started earlier than the previous > instructions. No store buffer flushing is done. Yes, I know that, and tried to find a way to flush store buffers faster. Hmm, unfenced rdtsc is correct and good as an optimization in some contexts. This program is an example. It doesn't matter for monotonicity or for getting an upper bound on time differences if the start time is in the past. >> Similar IPC is needed for updating timecounters. This benchmark indicates >> that after an update, the change usually won't be visible on other CPUs >> for 100+ cycles. Since updates are rare, this isn't much of a problem. >> >> Similar IPC is needed for comparing timecounters across CPUs. Any activity >> on different CPUs is incomparable without synchronization to establish an >> ordering. Since fences give ordering relative to memory and timecounters >> don't use anything except fences and memory order for the generation count >> to establish their order, the synchronization for comparing timecounters >> (or clock_gettime() at higher levels) must also use memory order. >> >> If the synchronization takes over 100 cycles, then smaller TSC skews don't >> matter much (they never break monotonicity, and only show up time differences >> varying by 100 or so cycles depending on which CPU measures the start and >> end events). Small differences don't matter at all. Skews may be caused > It should be more than 100 cycles for inter-socket IPC, but then genuine > RDTSC scew can accumulate much larger than 100, which is my worry. If it can accumulate at all, then it will soon accumulate to a huge value. 1 part per billion drift is 86400*4 cycles/day at 4HGHz. Since we haven't seen this, the hardware must be doing something right (or we don't have the large hardware that has problems). >> by the TSCs actually being out of sync, or hardware only syncing them on >> average (hopefully with small jitter) or bugs like missing fences. Missing >> fences don't matter much provided unserialized TSC reads aren't too far >> in the past. E.g., if we had a guarantee of only 10 cycles in the past for >> the TSC and 160 cycles for IPCs to other CPUs, then we could omit the fences. >> But IPCs to the same core are 100 cycles faster so the margin is too close >> for ommitting fences in all cases. > I have no idea if RDTSC is allowed to execute before (in program order) > earlier cache miss. If it is, then non-fenced RDTSC would easily give > much larger error than IPC sync delay. Yes, the fences are needed in general. But can we avoid them in the usual case where the program doesn't do any explicit IPCs? clock_gettime() and kernel time calls must be monotonic within a single thread. Hopefully this is automatic when the thread stays on a single CPU (this only requires rdtsc() to be monotonic. This is not as accurate as possible, but the inaccuracies are no worse than ones for delays from cache misses). Time-related IPCs are needed when the thread is moved to a different CPU. Schedulers don't understand this, but I think they do enough locking and delays to give the same effect. They could do 1 fence instruction per context switch to serialize TSCs more intentionally. This is probably faster than 1 fence instruction per timecounter call. Applications that want to compare times across threads should do the IPCs explicitly. This should be in a library function, and the library function can sprinkle fences too. Bruce From owner-freebsd-ppc@freebsd.org Thu Mar 14 19:39:56 2019 Return-Path: Delivered-To: freebsd-ppc@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 762E2152925C; Thu, 14 Mar 2019 19:39:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 B1A1C8E56D; Thu, 14 Mar 2019 19:39:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2EJdmBX061154 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 21:39:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2EJdmBX061154 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2EJdkor061152; Thu, 14 Mar 2019 21:39:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 21:39:46 +0200 From: Konstantin Belousov To: Mark Millard Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] Message-ID: <20190314193946.GJ2492@kib.kiev.ua> References: <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190306172003.GD2492@kib.kiev.ua> <20190308001005.M2756@besplex.bde.org> <20190307222220.GK2492@kib.kiev.ua> <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:39:56 -0000 On Thu, Mar 07, 2019 at 05:29:51PM -0800, Mark Millard wrote: > A basic question and a small note. > > Question's context for it tc->tc_get_timecount(tc) values: > > In the powerpc64 context tc->tc_get_timecount(tc) is the lower > 32 bits of the tbr, in my context having a 33,333,333 MHz or so > increment rate for a machine with a 2.5 GHz or so clock rate. > The truncated 32 bit tbr value wraps every 128 seconds or so. > 2 sockets, 2 cores per socket, so 4 separate tbr values. > > The question is . . . > > In tc_delta's: > > tc->tc_get_timecount(tc) - th->th_offset_count > > is observing tc->tc_get_timecount(tc) < th->th_offset_count > ever supposed to be possible in correct operation, other than > tc->tc_get_timecount(tc) having wrapped around (and so being > newly 0 or "near" 0, no evidence of of having it having been > near 128 seconds or more for my context)? I think yes, there is no reason for current get_timecount() value to have any arithmetic relation to th_offset_count. Look at tc_windup() on how the th_offset_count is calculated. The final value is clamped by the tc_counter_mask, so only lower bits are important (higher bits are evacuated to th_offset or lost due to overflow if tc_windup() was not called soon enough). > > > The note: > > On 2019-Mar-7, at 14:22, Konstantin Belousov wrote: > > > . . . > > + > > + if (__predict_false(delta < large_delta)) { > > I thought that delta for scale*delta and that the overflow case for the multiplication > was when delta>=large_delta . You are right, I fixed this in my repo. > > > + /* Avoid overflow for scale * delta. */ > > + x = (scale >> 32) * delta; > > + bt->sec += x >> 32; > > + bintime_addx(bt, x << 32); > > + bintime_addx(bt, (scale & 0xffffffff) * delta); > > + } else { > > + bintime_addx(bt, scale * delta); > > + } > > . . . > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Mar 14 19:57:28 2019 Return-Path: Delivered-To: freebsd-ppc@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 C3941152A25E; Thu, 14 Mar 2019 19:57:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3790D680D2; Thu, 14 Mar 2019 19:57:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id CD53848B9FA; Fri, 15 Mar 2019 06:57:17 +1100 (AEDT) Date: Fri, 15 Mar 2019 06:57:16 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Mark Millard , Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] In-Reply-To: <20190314193946.GJ2492@kib.kiev.ua> Message-ID: <20190315064830.F7981@besplex.bde.org> References: <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190306172003.GD2492@kib.kiev.ua> <20190308001005.M2756@besplex.bde.org> <20190307222220.GK2492@kib.kiev.ua> <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> <20190314193946.GJ2492@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=nzRIfmPsLuHBWj42Ri8A:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 3790D680D2 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:57:29 -0000 On Thu, 14 Mar 2019, Konstantin Belousov wrote: > On Thu, Mar 07, 2019 at 05:29:51PM -0800, Mark Millard wrote: >> A basic question and a small note. >> >> Question's context for it tc->tc_get_timecount(tc) values: >> >> In the powerpc64 context tc->tc_get_timecount(tc) is the lower >> 32 bits of the tbr, in my context having a 33,333,333 MHz or so >> increment rate for a machine with a 2.5 GHz or so clock rate. >> The truncated 32 bit tbr value wraps every 128 seconds or so. >> 2 sockets, 2 cores per socket, so 4 separate tbr values. >> >> The question is . . . >> >> In tc_delta's: >> >> tc->tc_get_timecount(tc) - th->th_offset_count >> >> is observing tc->tc_get_timecount(tc) < th->th_offset_count >> ever supposed to be possible in correct operation, other than >> tc->tc_get_timecount(tc) having wrapped around (and so being >> newly 0 or "near" 0, no evidence of of having it having been >> near 128 seconds or more for my context)? > I think yes, there is no reason for current get_timecount() value > to have any arithmetic relation to th_offset_count. Look at tc_windup() > on how the th_offset_count is calculated. The final value is clamped > by the tc_counter_mask, so only lower bits are important (higher bits > are evacuated to th_offset or lost due to overflow if tc_windup() > was not called soon enough). Yes, it is a standard method to calculate time differences from a possibly- wrapped counter as (finish - start) & mask in unsigned arithmetic, where the counter must be checked before it wraps relative to 'start'. >> The note: >> >> On 2019-Mar-7, at 14:22, Konstantin Belousov wrote: >> >>> . . . >>> + >>> + if (__predict_false(delta < large_delta)) { >> >> I thought that delta> for scale*delta and that the overflow case for the multiplication >> was when delta>=large_delta . > You are right, I fixed this in my repo. >> >>> + /* Avoid overflow for scale * delta. */ >>> + x = (scale >> 32) * delta; >>> + bt->sec += x >> 32; >>> + bintime_addx(bt, x << 32); >>> + bintime_addx(bt, (scale & 0xffffffff) * delta); >>> + } else { >>> + bintime_addx(bt, scale * delta); >>> + } >>> . . . Fixed in my version too. I might have helped break this. I reversed the condition to get the unusual path executed (though not when it overflow), and forgot to undo this. At least the unusual path got checked more). Bruce From owner-freebsd-ppc@freebsd.org Thu Mar 14 20:07:35 2019 Return-Path: Delivered-To: freebsd-ppc@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 E7760152A7D6; Thu, 14 Mar 2019 20:07:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 26B1D69BC8; Thu, 14 Mar 2019 20:07:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2EK7Rjh068145 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 22:07:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2EK7Rjh068145 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2EK7RK4068144; Thu, 14 Mar 2019 22:07:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 22:07:27 +0200 From: Konstantin Belousov To: Bruce Evans Cc: Mark Millard , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) Message-ID: <20190314200726.GK2492@kib.kiev.ua> References: <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> <20190313190558.GB2492@kib.kiev.ua> <20190315034923.S7485@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190315034923.S7485@besplex.bde.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 20:07:35 -0000 On Fri, Mar 15, 2019 at 06:37:26AM +1100, Bruce Evans wrote: > On Wed, 13 Mar 2019, Konstantin Belousov wrote: > > > On Wed, Mar 06, 2019 at 12:19:38AM +1100, Bruce Evans wrote: > > >> [... tscdrift.c] > >> I understand this program again. First, its name is actually tscdrift. > >> I tested the 2015 version, and this version is still in > >> /usr/src/tools/tools/tscdrift/tscdrift.c, with no changes to except to > >> the copyright (rgrimes wouldn't like this) and to $FreeBSD$. > >> > >> The program doesn't actually measure either TSC drift or TSC skew, except > >> indirectly. What it actually measures is the IPC (Inter-Process- > >> Communication) time for synchronizing the drift and skew measurments, > >> except bugs or intentional sloppiness in its synchronization also make it > >> give an indirect measurement of similar bugs or sloppiness in normal use. > >> > >> After changing TESTS from 1024 to 1024000, it shows large errors in the > >> negative direction, as expected from either large negative skew or program > >> bugs: this is on freefall: > >> > >> XX CPU | TSC skew (min/avg/max/stddev) > >> XX ----+------------------------------ > >> XX 0 | 0 0 0 0.000 > >> XX 1 | -6148 108 10232 46.871 > >> XX 2 | 114 209 95676 163.359 > >> XX 3 | 96 202 47835 101.250 > >> XX 4 | -2223 207 34017 117.257 > >> XX 5 | -2349 206 33837 106.259 > >> XX 6 | -2664 213 33579 96.048 > >> XX 7 | -2451 212 49242 126.428 > > Note that freefall is single-socket. My belief is that due to the > > construction of the RDTSC on Intels, it is impossible for the counter > > to become scew on single socket. All cores are fed from the same > > input signal, and most likely, even read the same uncore counter. > > The later is less likely because RDTSC latency is quite low, but there > > might be additional hw tricks. > > The large negative numbers show that even for single-socket, there are > really large errors if times are compared without cross-CPU synchronization > by the program. Negative numbers are easily explained by the server thread being de-scheduled right after writing the command to memory but before reading RDTSC. > > Initial skews in hardware are presumably smaller. If the hardware skew > drifts then there is a large problem for the software to compensate. I > think that is unlikely to be a problem. It depends. On my SKL-X, BIOS does not sync RDTSC between cores at all, on single-core machine. > > In a recent commit, mav@ wrote that some Skylake systems only return even > values in rdtsc(), and some seem to have a much lower resolution of 180+ > (?) cycles. 180 cycles might be from the skew being that much and the > hardware refusing to return values closer than that, perhaps even on the > same CPU. > > I already pointed out discarding bits as in TSC-low doesn't work to avoid > comparing values that are too close. Rather the reverse. Compensating > for skews needs as much accuracy as possible starting with measuring them. > > > On the other hand, for multi-socket machines, I do not think there is > > anything except the external clock signal which would ensure that the > > counters stay in sync. > > > > I tried to imagine is there is any shared hardware on multi-socket Intel > > system which would give equal latency for accesses from different sockets, > > and it seems that there is no such hardware. Then it is trully impossible > > to observe the scew. > > Yes, it has relativistic problems too. A distance of 1 foot and a speed > of 4GHz gives a skew of at least 4 cycles in "absolute" time. > > > It might be possible to measure round-trip time separately, and then > > subtract it from the measured scew. > > The hardware can do that too, or at least provide some support. I think > the "absolute" time must be determined by a distributed clock. Since the > system is not usually under much acceleration, the relativistic problems > are small. The clock has a knowable constant propagation speed. Well, the reason why I started enumerating the hardware known to me on x86 for this purpose, is because initially I thought that I can sync two threads by reading HPET counter register on both cores, and then do RDTSC on the next tick (say when counter moves to next multiple of 1024 * 1024). But the problem is that HPET is in 'legacy' domain, being attached by direct connection to the socket with BSP, and other socket must access it through the legacy socket. Might be some arithmetic helps there, but I dropped further thinking. > > >> The negative "skews" occur because the server and the clients (1 client at > >> a time) read the TSC with uncontrolled timing after the server opens the > >> gate for this read (gate = 2). The IPC time is about 200 cycles to CPUs > >> on different cores. So when neither thread is preempted, the TSC on the > >> server is about 200 cycles in advance. Sometimes the server is preempted, > >> so it reads its TSC later than the client (a maximum of about 6148 cycles > >> later in this test). More often the client is preempted, since the IPC > >> time is march larger than the time between the server opening the gate and > >> the server reading its TSC. > >> > >> The server is also missing fencing for its TSC read, so this read may > >> appear to occur several cycles before opening the gate. This gives a > >> an error in the positive direction for the reported "skew" (the error > >> is actually in the positive direction for the reported IPC time). It > >> would be useful to measure this error by intentionally omitting fencing, > >> but currently it is just a small amount of noise on top of the noise from > >> preemption. > >> > >> After fixing the syncronization: > >> > >> XX CPU | TSC skew (min/avg/max/stddev) > >> XX ----+------------------------------ > >> XX 0 | 0 0 0 0.000 > >> XX 1 | 33 62 49161 57.652 > >> XX 2 | 108 169 33678 73.456 > >> XX 3 | 108 171 43053 119.256 > >> XX 4 | 141 169 41289 114.567 > >> XX 5 | 141 169 40035 112.755 > >> XX 6 | 132 186 147099 269.449 > >> XX 7 | 153 183 431526 436.689 > >> ... > >> I tried some locked atomic ops on 'gate') and mfence instead of lfence > >> to try to speed up the IPC. Nothing helped. We noticed long ago that > >> fence instructions tend to be even slower that locked atomic ops for > >> mutexes, and jhb guessed that this might be because fence instructions > >> don't do so much to force out stores. > > I am not sure I follow. MFENCE is documented by wording that implies, > > without any doubts, that store buffers are flushed before the > > instruction is retired. It is not so obvious for SFENCE, which > > sounds like a real fence instead of full flush, at least for normal > > write-back memory where it is NOP as far as ISA is considered. > > The program uses LFENCE partly because it is the documented method of > serializing rdtsc on Intel CPUs. It only gives serialization on 1 CPU. > > The locking protocol gives serialization of memory accesses and rdtsc's > across CPUs (after I fixed it). Only serialization of the rdtsc > instructions -- their results may still be out of order if there is skew > and the skew is larger than the IPC time. > > MFENCE is the documented method for serializing rdtsc on (some?) AMD CPUs, > it is just slower on freefall's Xeon CPUs. > > SFENCE has little affect on freefall's Xeon CPUs. It apparently doesn't > serialize rdtsc and is useless for the locking protocol. > > The locking protocol uses only load_acq, store_rel, fence_acq and fence_rel. > These are disguised as simple C operations and compiler memory barriers. > FENCE instructions apparently don't work for speeding up the store buffers. > > > It is known and documented in optimization manuals that locked > > operations are much more efficient, but locked ops are only documented > > to ensure ordering and not flush. So SFENCE is not suitable as our > > barrier. > > I tried them too. What are they more efficient for? Is it just that they > are local while fences are global? They are more efficient in enforcing the memory order as defined by C11 and atomic(9). E.g. 'lock add 0, per-cpu location' is faster than MFENCE but gives the same effects by ordering all writes before it vs. all reads after it. Neither fences nor locked instructions are global. If anything, locked instructions are more global because they must take the cache line into exclusive ownership, so they must invalidate it in all other caches. While fences only affect the local CPU pipeline and potentially wait for some local events like store buffer flushing (but SFENCE could not). > > > And, the second point, LFENCE there does not work as barrier for IPC. > > It only ensures that RDTSC is not started earlier than the previous > > instructions. No store buffer flushing is done. > > Yes, I know that, and tried to find a way to flush store buffers faster. > > Hmm, unfenced rdtsc is correct and good as an optimization in some contexts. > This program is an example. It doesn't matter for monotonicity or for > getting an upper bound on time differences if the start time is in the past. On anything newer than SandyBridge there is RDTSCP instruction which provides the required serialization automatically. > > >> Similar IPC is needed for updating timecounters. This benchmark indicates > >> that after an update, the change usually won't be visible on other CPUs > >> for 100+ cycles. Since updates are rare, this isn't much of a problem. > >> > >> Similar IPC is needed for comparing timecounters across CPUs. Any activity > >> on different CPUs is incomparable without synchronization to establish an > >> ordering. Since fences give ordering relative to memory and timecounters > >> don't use anything except fences and memory order for the generation count > >> to establish their order, the synchronization for comparing timecounters > >> (or clock_gettime() at higher levels) must also use memory order. > >> > >> If the synchronization takes over 100 cycles, then smaller TSC skews don't > >> matter much (they never break monotonicity, and only show up time differences > >> varying by 100 or so cycles depending on which CPU measures the start and > >> end events). Small differences don't matter at all. Skews may be caused > > It should be more than 100 cycles for inter-socket IPC, but then genuine > > RDTSC scew can accumulate much larger than 100, which is my worry. > > If it can accumulate at all, then it will soon accumulate to a huge value. > 1 part per billion drift is 86400*4 cycles/day at 4HGHz. Since we haven't > seen this, the hardware must be doing something right (or we don't have the > large hardware that has problems). I am not sure. Hopefully you are right. > > >> by the TSCs actually being out of sync, or hardware only syncing them on > >> average (hopefully with small jitter) or bugs like missing fences. Missing > >> fences don't matter much provided unserialized TSC reads aren't too far > >> in the past. E.g., if we had a guarantee of only 10 cycles in the past for > >> the TSC and 160 cycles for IPCs to other CPUs, then we could omit the fences. > >> But IPCs to the same core are 100 cycles faster so the margin is too close > >> for ommitting fences in all cases. > > I have no idea if RDTSC is allowed to execute before (in program order) > > earlier cache miss. If it is, then non-fenced RDTSC would easily give > > much larger error than IPC sync delay. > > Yes, the fences are needed in general. > > But can we avoid them in the usual case where the program doesn't do > any explicit IPCs? clock_gettime() and kernel time calls must be > monotonic within a single thread. Hopefully this is automatic when > the thread stays on a single CPU (this only requires rdtsc() to be > monotonic. I am not sure about this part as well. Rather, I expect that it is not true because RDTSC can be reordered with other instructions and then large delays like cache misses would cause significantly wrong measurements even for single-thread. > This is not as accurate as possible, but the inaccuracies > are no worse than ones for delays from cache misses). Time-related > IPCs are needed when the thread is moved to a different CPU. Schedulers > don't understand this, but I think they do enough locking and delays > to give the same effect. They could do 1 fence instruction per context > switch to serialize TSCs more intentionally. This is probably faster > than 1 fence instruction per timecounter call. Applications that want > to compare times across threads should do the IPCs explicitly. This > should be in a library function, and the library function can sprinkle > fences too. > > Bruce From owner-freebsd-ppc@freebsd.org Thu Mar 14 21:06:08 2019 Return-Path: Delivered-To: freebsd-ppc@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 14F36152E260 for ; Thu, 14 Mar 2019 21:06:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (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 A8F856D1B9 for ; Thu, 14 Mar 2019 21:06:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: b98A80QVM1ndr3O2RIri_T67nc11zhImn7xgJgXJsdFfSBstZLHBxUbkieqniOB sulCwsVOt9gP98cbicIbHoe7Rkm8l0EyvUaEPl95q_TxrLVFqTYN8iFBoebltuS6ST5s34.u8EuX 0w8kex.awM2djXZmfuSvD83uisryI.kZOR6oKlYjFze251hXY7FQ.KL_lslYsRuTKqbNsPHnPZlQ FoBRKenXxpk5SFSqMLeTWlOpGPZ6Oa5kRMNoleJRtX6THg0Vno4lHaHdOHgQQ.0BfglafvA6DT_A 4fY2sxv9dI7hQBB6sYc77Sj6PL4AP79kb.rnifvH4XlSZZdkhDi.61pIsv3VbT0ffYU0bYfr5gru RKgislDUBJg73CzCrF4N9libUUaEdcoMczq67wW7ldervDy6Ie2b3ULRREIlW7VyFxo3fqwS42E2 qRax6DBW_FV_xC4VCM8vYEOiQwjnw1zZjCLW3yOAO_8UlUsYSdr_iRm7SSQPoeubfmixFpETpuWb d7ffs4z2UYyF_WSIGm0LOV2DyRliXel_uErbdBfDS.0tarI_oQJU9u83xa5tiAMoaUYLFR1sVBLA R8QYRH9.c5jtTMfXwmWGmj.qQ2UvEvP7pz3NOvCNzh62mzEaLKitULMswSTYyRRTyAlufuEgajB4 QKHRajgftJLKdEoHhKCS4DHEVvvrmMONHQAau1ndn2aSdlmZuFbriIbTMiVCA5aq2vnGY_0CiR5b BtjdcZEcM6Ut0ZfztH67I_uDMuRZ6n348YVwuShHtfEv7TSzc4qi_cwdnn4hmKamx1IVE6UJEGAd xpIbRMaOynGn6VRRxzClgt8ljVcKZfezWITxugaUC8oxwVsCuE1tobBHqgFLSN1xnlXegW39TImJ sCb7yvfMzR5Cbjjc9fVP8dhb7J1.dbAacpYu9y3TDcfKspE5LIz2KnjsIvkc7YPDFPMS0212EvUc P6STZedz_U8_xbPrJ4pstaA6LGlI6gCj5NhdxDHHmamW5bqvuCOk2TEIM07bQ8eXt0x9ApJ1UDL0 5bPWHJUwyeNH80JGHZRqwgbS8YMeG4HwcgQ0ZkQ_UtHA6jiKcdlzbncT5WXl49BvS09oW51NNmKS .HWr7CA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 14 Mar 2019 21:06:00 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.113]) ([67.170.167.181]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9bb07e4b69e4d33f5b956231b2bf4305; Thu, 14 Mar 2019 21:06:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] From: Mark Millard In-Reply-To: <20190314193946.GJ2492@kib.kiev.ua> Date: Thu, 14 Mar 2019 14:05:57 -0700 Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190306172003.GD2492@kib.kiev.ua> <20190308001005.M2756@besplex.bde.org> <20190307222220.GK2492@kib.kiev.ua> <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> <20190314193946.GJ2492@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: A8F856D1B9 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 21:06:08 -0000 On 2019-Mar-14, at 12:39, Konstantin Belousov = wrote: > On Thu, Mar 07, 2019 at 05:29:51PM -0800, Mark Millard wrote: >> A basic question and a small note. >>=20 >> Question's context for it tc->tc_get_timecount(tc) values:=20 >>=20 >> In the powerpc64 context tc->tc_get_timecount(tc) is the lower >> 32 bits of the tbr, in my context having a 33,333,333 MHz or so >> increment rate for a machine with a 2.5 GHz or so clock rate. >> The truncated 32 bit tbr value wraps every 128 seconds or so. >> 2 sockets, 2 cores per socket, so 4 separate tbr values. >>=20 >> The question is . . . >>=20 >> In tc_delta's: >>=20 >> tc->tc_get_timecount(tc) - th->th_offset_count >>=20 >> is observing tc->tc_get_timecount(tc) < th->th_offset_count >> ever supposed to be possible in correct operation, other than >> tc->tc_get_timecount(tc) having wrapped around (and so being=20 >> newly 0 or "near" 0, no evidence of of having it having been >> near 128 seconds or more for my context)? > I think yes, there is no reason for current get_timecount() value > to have any arithmetic relation to th_offset_count. Look at = tc_windup() > on how the th_offset_count is calculated. The final value is clamped > by the tc_counter_mask, so only lower bits are important (higher bits > are evacuated to th_offset or lost due to overflow if tc_windup() > was not called soon enough). >=20 Okay. Thanks. Just FYI: I asked because in my powerpc64 context I was seeing (in sleepq_timeout) td->td_sleeptimo > sbinuptime() in: if (td->td_sleeptimo > sbinuptime() || td->td_sleeptimo =3D=3D = 0) { /* * The thread does not want a timeout (yet). */ and without such sleeps being rescheduled in that case, those sleeps hang up. My hack to temporarily enable useful operation was to have binuptime avoid tc->tc_get_timecount(tc) < th->th_offset_count for small enough differences, as shown below: . . . do { do { // HACK!!! th=3D timehands; tc=3D th->th_counter; gen=3D atomic_load_acq_int(&th->th_generation); tim_cnt=3D tc->tc_get_timecount(tc); tim_offset=3D th->th_offset_count; tim_wrong_order_diff=3D tim_offset-tim_cnt; } while (tim_cntth_offset; . . . where I experimentally came up with the following for the specific = PowerMac G5 context: u_int const wrong_order_diff_proper_upper_bound=3D 0x14u; // = 0x11 is max observed diff so far HACK!!! I've not hand any hung-up sleeps after that change. Despite being a = hack, this gives evidence that tc->tc_get_timecount(tc) < th->th_offset_count for small enough differences (in binuptime) is involved in the hangups in some essential way for the PowerMac G5 context. I look forward to removing this hack at some point, when things just work for this 2 socket, 2 cores per socket powerpc64 context. But for now the hack is locally useful. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Mar 15 01:33:49 2019 Return-Path: Delivered-To: freebsd-ppc@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 26E701536A5C for ; Fri, 15 Mar 2019 01:33:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 83807779ED for ; Fri, 15 Mar 2019 01:33:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: wRZX4gQVM1m7oWD3udlOD3dUMYjwmQ.VHBJ1Ay2Igtg2V4FNnDODcL6VqFRLIBF RXqIORRTt6iSpsxGLxheu57QsYMrF_RLS7RRRZhSbd5PR9PCOvxpbPY.K3Omy9.UuRkG_VMkMMVx aIiLScx4v1lIGL6V6eQIf6kVuvBn7CJhWhAX6E9sTsm1RB5xD9WS9xQT4TvwDpZB78K_I8m8GzWR ejuJyJM3wvT.c0bRHC3pvExtMQJsZOsmLCH2oT1OQIOeEg1KmlC19rNMCLQ3gOIFp53_0b_fvUTc .wQdZ9hTgAvRh8CWw0kmHQBxC6On373KqSdDSu.k5q1NIrSxRgm7aFITYh50yiCbqo_lNcL9U4bh qzdJ3OzP68SlTKBQy7Y721GQjGmyXMbztB.ij8uHvBwjNbAaBHKvr6lxin5iLzU6bbQv8iynY4jb 7oeAewcxdMGGh0EaxWeF87eN1AUKjFup8Fe_x8cOzTf9rNqc9Bg9Slb24AY31panoG591wYUWKjN XbEUPLxNGZaJgE8EZy3.orEexwzZcq05X8WzHEtxN6RMePZEQeUisaiwWwyKSctOTbSe5IJfPX6q ZGBqsX0ripuuP8LP8Qy8jbnhdWORnjgzCeSt5pYdOcZfwlkgSJGHEsF2uTArJooFWDa5CuFRoP1b LUS_4SwdlkKsEhIDJAlKsR4CoePiq0bs16l9EPqrpRmo9ncLD6PLBA8NuAy3ga7kwsNpUvR3Qa5X NDv7iWpjiyS7CgWKPh73L46uDePyGbm.7z8WZVU7rwKSWiJCWMssvsg0yUOn2NDALy6jDX2exIzQ CByzGjRUUSzzzW92vxYSeyvHqBdxxDmKNwr_TW8Wcbd30AiglM7wKKB0YJ7KJDvtaPlSxAmOw4s3 QtvncT8eNL36VKG_Z7Ayp5txJLgO8AaCT8alzeyR8BnjCBaMwx4xio9lz8vT1qD0HvcnA8poKOBh XJgJwTfINILpkcTlP0LC4StChR7DNvXDEEcVH6QYI2FCZ0_ZoPCTv2E_OBa4ogiMAVTFobf_a5rA _M3n4oRRvZUdebHoBN84kh4Fc5YjJwfGLRwSc1uE2Lt__BlXUUHVvCamP8PBZaE4_cmoQPexZDoH adlPIR8Hd Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Mar 2019 01:33:40 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp403.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 39434808bbff3548ebbad8c6df877feb; Fri, 15 Mar 2019 01:23:31 +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 12.2 \(3445.102.3\)) Subject: Re: llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code Date: Thu, 14 Mar 2019 18:23:30 -0700 References: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> <2429D922-3214-4D40-9616-56BC0CB93A15@yahoo.com> To: FreeBSD Toolchain , FreeBSD PowerPC ML In-Reply-To: <2429D922-3214-4D40-9616-56BC0CB93A15@yahoo.com> Message-Id: <795BBC02-6CE9-401E-8D9F-84FB9FB31364@yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 83807779ED X-Spamd-Bar: - X-Spamd-Result: default: False [-1.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.75)[-0.749,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.49)[0.492,0]; NEURAL_HAM_LONG(-0.98)[-0.983,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.34)[ipnet: 98.137.64.0/21(0.98), asn: 36647(0.78), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[206.68.137.98.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 01:33:49 -0000 [ELFv2 vs. ELFv1 ABI differences may lead to the fix only applying to one of them: ELFv2's ABI.] On 2019-Mar-13, at 19:14, Mark Millard wrote: > On 2019-Mar-12, at 22:08, Mark Millard wrote: >=20 >> I have submitted: >>=20 >> https://bugs.llvm.org//show_bug.cgi?id=3D41050 >>=20 >> for the clang 8 code generation problem of >> no code for setting r2 appropriately before >> the: >>=20 >> bl . . . <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> >>=20 >> in unoptimized code ( no -O ). For the -O2 code: >>=20 >> ld r2,40(r1) >>=20 >> is present but is being skipped by the libunwind return >> to the code: it returns to the just-following bl >> instruction (like above) instead. >>=20 >> In both cases: >>=20 >> (gdb) x/32i 0x100007c0 >> 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) >> 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) >> 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 >> 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) >> 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) >> 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr >> 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 >> 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 >> . . . >>=20 >> with an inappropriate r2 value leads to jumping to >> inappropriate places. >>=20 >> The example source code was: >>=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >>=20 >>=20 >> Note: >>=20 >> This is from investigations of head -r345044 using >> WITH_LLVM_LIBUNWIND=3D on powerpc64. >>=20 >=20 > The discussion on https://bugs.llvm.org//show_bug.cgi?id=3D41050 > indicates that the ld r2,??? to restore the value appropriate to > the a.out code in my example should be happening via the library > holding libunwind's code instead of the ld executing in the > a.out code. >=20 > So: thus far it is viewed as a libunwind issue instead of a clang > one. Both ELFv2 and ELFv1 are currently broken because of r2 (TOC) mishanding. Looks like that when libunwind is fixed, it might not support the ELFv1 ABI (just the ELFv2 ABI): handling r2 (TOC) is different because of the differences in the stack frame header . . . ELFv1 has r2 save area at 40(r1) [because of the compiler and = link-editor doublewords] ELFV2 has r2 save area at 24(r1) [no compiler or link-editor = doublewords] A simple update to libunwind/src/UnwindRegistersRestore.S for = powerpc64's _ZN9libunwind15Registers_ppc646jumptoE is (an ELFv2 ABI example): - PPC64_LR(2) + // skip r2 for now and: PPC64_LR(4) PPC64_LR(1) PPC64_LR(3) + ld %r2, 24(%r1) bctr (That is from comment #16.) I've no clue if more would be done to handle the ELFv1 ABI as well. As I understand FreeBSD plans to support the ELFv2 ABI at some point. I'm not sure of the intent after that for the ELFv1 ABI. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Mar 15 22:17:14 2019 Return-Path: Delivered-To: freebsd-ppc@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 4831D1530BC6 for ; Fri, 15 Mar 2019 22:17:14 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30BA68699C for ; Fri, 15 Mar 2019 22:17:13 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-ot1-x32f.google.com with SMTP id f10so2272187otb.6 for ; Fri, 15 Mar 2019 15:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=4FI/LkCQhgXR9a+1D0PysRF1ib9ztOaFtY3jklAB74I=; b=RFdDt+SLuS1HzYc/ZpZmxSORwIA8Bjtz4CIgNqIoks1WZ2mCGdnIHneq8/vbhgweiJ vUpoGjqIGjD+m2phhQ5ziuX8GicnCBjpjqyUWvlX7tOG2dJEckD37FHIvQXnmNCD6IyT j+PBJGCsT/FVSV3Uq0dlKWO93xKDfchAMuBmtd+3EC9VhbIEkwTi/4i/djvjbQVchupZ /OqY/uX1Lh3kG71MtarvXLX3u2DGFdykXZKivpFiyjdjhij1Ri1MhJWbA5CEcXXwswsl 6t9Ld0jBzWGN+G+TbatgQSGDpCWbxEWUQTjtrC5XKTKNyE2yhq18N0c6Z+QYCTagnNG/ trrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=4FI/LkCQhgXR9a+1D0PysRF1ib9ztOaFtY3jklAB74I=; b=p/1msG4tO1iVvdRb03hspYXH5lK+6x/YA/IE9qKh9W5b4DTilJ48vF7WqcG5vyTsYm CkVixFqRJww/FTmaV/dMhdltIW03ZUrPASfBWnidiIBZVd+KS19Wt/OarKe0AMbZ5RjA MxVSMSwZoyqKEEor0frL5kwkXOqai5TX0R/BoFeZgitISnqQfHIzI4ROmfz/uwQdlbeF 4WL/oBjennuX9dMZAPB4ZU23pB+Y5LXQo/kcRXT4jCgR6i+Y3JwjhJCIrLm7yj+RZT6U TaCBWguFCgCWjfkc4HMyTFVQSE7ahBM0zj7NHHQkkP3xu9kQ48Ev1TY7cBDU/ePiJF2E O7Yw== X-Gm-Message-State: APjAAAVhhSbmOHmPwbo1S7g6fBwvA0PHTNAInhANg8do5gyTynrk04qA NW4pRuQJ+oGTzwCgLed1y112LWpM X-Google-Smtp-Source: APXvYqwzuFHKe6zBZmQCIcOjWvY78PROp+J5SREULIc0qMhpz0WOzFa5kmBFSPmV0XQL8tqMtUuY2A== X-Received: by 2002:a05:6830:151a:: with SMTP id k26mr3330147otp.8.1552688232183; Fri, 15 Mar 2019 15:17:12 -0700 (PDT) Received: from thinkpad.localdomain ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id x202sm1400330oix.25.2019.03.15.15.17.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 15:17:11 -0700 (PDT) To: freebsd-ppc@freebsd.org From: Karel Gardas Subject: pkg install package size mismatch Message-ID: Date: Fri, 15 Mar 2019 23:17:05 +0100 User-Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 30BA68699C X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=RFdDt+SL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gardask@gmail.com designates 2607:f8b0:4864:20::32f as permitted sender) smtp.mailfrom=gardask@gmail.com X-Spamd-Result: default: False [-6.72 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.96)[-0.960,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.75)[ip: (-8.89), ipnet: 2607:f8b0::/32(-2.73), asn: 15169(-2.08), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[f.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 22:17:14 -0000 Hello, I'm running up-to-date 13.0-current on PowerKVM and while trying to install cmake I've hit "size mismatch" error. My guess is that pkg tries to contact repo mirror not fully updated yet or not fully in-sync. However I'm just FreeBSD beginner so I'd like to ask if there are other explanations for this error, especially if there may be some mistake on user side. Whole error output is provided below. Thanks, Karel # pkg install cmake Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 9 package(s) will be affected (of 0 checked): New packages to be INSTALLED:         cmake: 3.13.4         rhash: 1.3.5         curl: 7.64.0_1         libnghttp2: 1.36.0         libuv: 1.26.0         jsoncpp: 1.8.1_6         libarchive: 3.3.3,1         lzo2: 2.10_1         liblz4: 1.8.3,1 Number of packages to be installed: 9 The process will require 38 MiB more space. 7 MiB to be downloaded. Proceed with this action? [y/N]: y [1/9] Fetching cmake-3.13.4.txz: 100%    4 MiB   2.3MB/s    00:02 pkg: cached package cmake-3.13.4: size mismatch, fetching from remote [2/9] Fetching cmake-3.13.4.txz: 100%    4 MiB   2.3MB/s    00:02 pkg: cached package cmake-3.13.4: size mismatch, cannot continue From owner-freebsd-ppc@freebsd.org Sat Mar 16 16:53:35 2019 Return-Path: Delivered-To: freebsd-ppc@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 3A0F515352DF for ; Sat, 16 Mar 2019 16:53:35 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6363D6ADB5 for ; Sat, 16 Mar 2019 16:53:33 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.101] (67-0-223-146.albq.qwest.net [67.0.223.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 8D0AE1AF608; Sat, 16 Mar 2019 09:09:48 +0000 (UTC) Subject: Re: pkg install package size mismatch To: Karel Gardas , freebsd-ppc@freebsd.org References: From: Sean Bruno Openpgp: preference=signencrypt Autocrypt: addr=sbruno@freebsd.org; prefer-encrypt=mutual; keydata= mQENBFk+0UEBCADaf4bgxxKvMOhRV5NPoGWRCCGm49d6+1VFNlQ77WsY/+Zvf95TPULdRlnG w648KfxWt7+O3kdKhdRwnqlXWC7zA2Qt0dRE1yIqOGJ4jp4INvp/bcxWzgr0aoKOjrlnfxRV bh+s0rzdZt6TsNL3cVYxkC8oezjaUkHdW4mFJU249U1QJogkF8g0FeKNfEcjEkwJNX6lQJH+ EzCWT0NCk6J+Xyo+zOOljxPp1OUfdvZi3ulkU/qTZstGVWxFVsP8xQklV/y3AFcbIYx6iGJ4 5L7WuB0IWhO7Z4yHENr8wFaNYwpod9i4egX2BugbrM8pOfhN2/qqdeG1L5LMtXw3yyAhABEB AAG0N1NlYW4gQnJ1bm8gKEZyZWVCU0QgRGV2ZWxvcGVyIEtleSkgPHNicnVub0BmcmVlYnNk Lm9yZz6JAVQEEwEKAD4WIQToxOn4gDUE4eP0ujS95PX+ibX8tgUCWT7RQQIbAwUJBaOagAUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRC95PX+ibX8ttKTCACFKzRc56EBAlVotq02EjZP SfX+unlk6AuPBzShxqRxeK+bGYVCigrYd1M8nnskv0dEiZ5iYeND9HIxbpEyopqgpVTibA7w gBXaZ7SOEhNX1wXwg14JrralfSmPFMYni+sWegPMX/zwfAsn1z4mG1Nn44Xqo3o7CfpkMPy6 M5Bow2IDzIhEYISLR+urxs74/aHU35PLtBSDtu18914SEMDdva27MARN8mbeCDbuJVfGCPWy YHuy2t+9u2Zn5Dd+t3sBXLM9gpeaMm+4x6TNPpESygbVdh4tDdjVZ9DK/bWFg0kMgfZoaq6J l0jNsQXrZV3bzYNFbVw04pFcvA2GIJ7xuQENBFk+0UEBCADIXBmQOaKMHGbc9vwjhV4Oj5aZ DdhNedn12FVeTdOXJvuTOusgxS29lla0RenHGDsgD08UiFpasBXWq/E+BhQ19d+iRbLLR17O KKc1ZGefoVbLARLXD68J5j4XAyK+6k2KqBLlqzAEpHTzsksM9naARkVXiEVcrt6ciw0FSm8n kuK3gDKKe93XfzfP+TQdbvvzJc7Fa+appLbXz61TM1aikaQlda8bWubDegwXbuoJdB34xU1m yjr/N4o+raL0x7QrzdH+wwgrTTo+H4S2c1972Skt5K5tbxLowfHicRl23V8itVQr3sBtlX4+ 66q+Apm7+R36bUS/k+G45Sp6iPpxABEBAAGJATwEGAEKACYWIQToxOn4gDUE4eP0ujS95PX+ ibX8tgUCWT7RQQIbDAUJBaOagAAKCRC95PX+ibX8trrIB/9Pljqt/JGamD9tx4dOVmxSyFg9 z2xzgklTLuDgS73MM120mM7ao9AQUeWiSle/H0UCK7xPOzC/aeUC4oygDQKAfkkNbCNTo3+A qDjBRA8qx0e9a/QjDL+RFgD4L5kLT4tToY8T8HaBp8h03LBfk510IaI8oL/Jg7vpM3PDtJMW tUi2H+yNFmL3NfM2oBToWKLFsoP54f/eeeImrNnrlLjLHPzqS+/9apgYqX2Jwiv3tHBc4FTO GuY8VvF7BpixJs8Pc2RUuCfSyodrp1YG1kRGlXAH0cqwwr0Zmk4+7dZvtVQMCl6kS6q1+84q JwtItxS2eXSEA4NO0sQ3BXUywANh Message-ID: Date: Sat, 16 Mar 2019 10:53:26 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kVjF0CxzcDThUPQrBmyTxBOQCK6QfnwmE" X-Rspamd-Queue-Id: 6363D6ADB5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 16:53:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kVjF0CxzcDThUPQrBmyTxBOQCK6QfnwmE Content-Type: multipart/mixed; boundary="4PrE6Sii1HGPC5AAtQrExR1xSyU3l3rhN"; protected-headers="v1" From: Sean Bruno To: Karel Gardas , freebsd-ppc@freebsd.org Message-ID: Subject: Re: pkg install package size mismatch References: In-Reply-To: --4PrE6Sii1HGPC5AAtQrExR1xSyU3l3rhN Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/15/19 4:17 PM, Karel Gardas wrote: > Hello, >=20 > I'm running up-to-date 13.0-current on PowerKVM and while trying to > install cmake I've hit "size mismatch" error. My guess is that pkg trie= s > to contact repo mirror not fully updated yet or not fully in-sync. > However I'm just FreeBSD beginner so I'd like to ask if there are other= > explanations for this error, especially if there may be some mistake on= > user side. Whole error output is provided below. >=20 > Thanks, > Karel >=20 >=20 > # pkg install cmake > Updating FreeBSD repository catalogue... > FreeBSD repository is up to date. > All repositories are up to date. > The following 9 package(s) will be affected (of 0 checked): >=20 > New packages to be INSTALLED: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cmake: 3.13.4 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rhash: 1.3.5 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 curl: 7.64.0_1 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 libnghttp2: 1.36.0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 libuv: 1.26.0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 jsoncpp: 1.8.1_6 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 libarchive: 3.3.3,1 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lzo2: 2.10_1 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 liblz4: 1.8.3,1 >=20 > Number of packages to be installed: 9 >=20 > The process will require 38 MiB more space. > 7 MiB to be downloaded. >=20 > Proceed with this action? [y/N]: y > [1/9] Fetching cmake-3.13.4.txz: 100%=C2=A0=C2=A0=C2=A0 4 MiB=C2=A0=C2=A0= 2.3MB/s=C2=A0=C2=A0=C2=A0 00:02 > pkg: cached package cmake-3.13.4: size mismatch, fetching from remote > [2/9] Fetching cmake-3.13.4.txz: 100%=C2=A0=C2=A0=C2=A0 4 MiB=C2=A0=C2=A0= 2.3MB/s=C2=A0=C2=A0=C2=A0 00:02 > pkg: cached package cmake-3.13.4: size mismatch, cannot continue >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" If you do a "pkg update -f" and then a "pkg install cmake" does this fix your problem? sean --4PrE6Sii1HGPC5AAtQrExR1xSyU3l3rhN-- --kVjF0CxzcDThUPQrBmyTxBOQCK6QfnwmE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAlyNKgxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /LZ3NAgAt6DQEQz4HIyDJAKcHslX0DVWDcVVbPqoQiiEErisfMOJKhIBcI5L3d2C zGVQ58YfN737McpHZ/3RrtyjEChjeWKayJ4kJe102RR6nFKjwOg+FCv/6wtLgKTS LsMDlT2cHyKILZdf616m30ejx6kfCZaAQ7aghNNVVqMPXQ+L9ue//TfuuHLxhmlp wG8jKhKvXOeolaQOcNLVpiS/u/XG1PDWUxSbGqV+4gIlzG1cdQUPZ4uo6URyLMkb FXFTYgJPZo/kd+Hj9osI9Mw9SN6WAyBA8Gq1BBSGQsjZf/bvt1RnxA1ERSeQoFU7 WZbpN56SxEBTko2IfEJOq1cq6cCqrw== =bnjN -----END PGP SIGNATURE----- --kVjF0CxzcDThUPQrBmyTxBOQCK6QfnwmE-- From owner-freebsd-ppc@freebsd.org Sat Mar 16 22:51:58 2019 Return-Path: Delivered-To: freebsd-ppc@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 1B08A1540AEE for ; Sat, 16 Mar 2019 22:51:58 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5907D80620; Sat, 16 Mar 2019 22:51:56 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-wm1-x332.google.com with SMTP id u10so6677404wmj.5; Sat, 16 Mar 2019 15:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=FaVfM9Fo8AdSKGSqvxZtSvJ0eiK+qBqR4g4NsreVvpA=; b=twUuc+O/8UG/eJeaFdvnaOFXfqezmbNF9SySguxLY2b/ZZ7EoKaYjbfoEyrsBpDgby dWlA/8s6rDGkJgm7swevSLKKSgy/ZO6ygXEmrcAfhvWZf5Ibo0po5bKEFAAFKw2UjB9R +z82Dd0+KHkcBl6662eA9oaGyDzIGRwU0GfZVPKC8KOYORao15Ui42X8+dKXm7rdmcg9 7ue/m9/PikYtXIX0OstOEwDn5ZY911pwnOfb/D4WJIohqV4oztxE9+Qk6LaqBqsIk+9B CwRR92FDmrsFX+/pGm3VJI2fcdUd9dXSrHYEROEf2i627o2GbCec8GxXYXrAuNQdCU2j ozRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FaVfM9Fo8AdSKGSqvxZtSvJ0eiK+qBqR4g4NsreVvpA=; b=pTkFI+vQY1ZXwi2WIH1LrqYRSjP4LEjqQUKvODRrYtJ5+4eXDYkTkdN7WZy9lfIkXA xb9XgiTu9jJpiAa1mJLJIBe2Out4ZvuK86w9Yaq9y57ZJtoZuFHAeqfArG8sIpk0NIb9 IW2luvlY3t0O10DSnuLC402bIpKzXmAdwQlJZAWyBfOG+zkPsDeB4haVmHkv4dGrXNGw 8Xra++zJTJLWeutFSNoTk3MARHWnnACZaQ7eXd8BjtCgY/rRVuwrVo7wXZ++/92z/IMW WFCk115+D+Q2HAfgrxjL3PcFjQ0/VE3h8Bl2JfLeInSO6Va2XwhfDWnqZvNfgUQ4q60E LBSQ== X-Gm-Message-State: APjAAAVOa2Xyut0z9h5N93N9DOkc/899pHdUZ5Cf23KzPrxHmq99esGE v9rdzveKKtpzDseSB9zHR83z5/oN X-Google-Smtp-Source: APXvYqwo55CaTVg2ccyVmwp6n4P8+urSE4UMlth3nccp1Xu3tQd5FowVjiB/4BBs45cIgwTlCQnL/w== X-Received: by 2002:a7b:cc19:: with SMTP id f25mr2103777wmh.8.1552776714956; Sat, 16 Mar 2019 15:51:54 -0700 (PDT) Received: from thinkpad.localdomain ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id y12sm5069924wma.44.2019.03.16.15.51.53 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 16 Mar 2019 15:51:54 -0700 (PDT) Subject: Re: pkg install package size mismatch To: Sean Bruno , freebsd-ppc@freebsd.org References: From: Karel Gardas Message-ID: Date: Sat, 16 Mar 2019 23:51:51 +0100 User-Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 5907D80620 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=twUuc+O/; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gardask@gmail.com designates 2a00:1450:4864:20::332 as permitted sender) smtp.mailfrom=gardask@gmail.com X-Spamd-Result: default: False [-6.83 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.83)[ip: (-9.65), ipnet: 2a00:1450::/32(-2.36), asn: 15169(-2.08), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[2.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 22:51:58 -0000 On 3/16/19 5:53 PM, Sean Bruno wrote: > > On 3/15/19 4:17 PM, Karel Gardas wrote: >> Proceed with this action? [y/N]: y >> [1/9] Fetching cmake-3.13.4.txz: 100%    4 MiB   2.3MB/s    00:02 >> pkg: cached package cmake-3.13.4: size mismatch, fetching from remote >> [2/9] Fetching cmake-3.13.4.txz: 100%    4 MiB   2.3MB/s    00:02 >> pkg: cached package cmake-3.13.4: size mismatch, cannot continue >> >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > > If you do a "pkg update -f" and then a "pkg install cmake" does this fix > your problem? > > sean > Thanks for the help, this indeed helps! Karel