From owner-freebsd-toolchain@freebsd.org Wed Mar 13 03:24:41 2019 Return-Path: Delivered-To: freebsd-toolchain@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 181E3154847E 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 219C9927DA 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: 219C9927DA 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-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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)