Date: Sat, 27 Feb 2016 23:17:52 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 207325] projects/clang380-import for TARGET_ARCH=powerpc : c++ exceptions cause SEGV (9 line program) Message-ID: <bug-207325-8-rfoV1vEDZE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-207325-8@https.bugs.freebsd.org/bugzilla/> References: <bug-207325-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207325 --- Comment #6 from Mark Millard <markmi@dsl-only.net> --- I've tracked this down to misbehavior of clang 3.8.0 for __builtin_dwarf_cf= a () for TARGET_ARCH=3Dpowerpc in: #define uw_init_context(CONTEXT) \ do \ { \ /* Do any necessary initialization to access arbitrary stack frames. \ On the SPARC, this means flushing the register windows. */ \ __builtin_unwind_init (); \ uw_init_context_1 (CONTEXT, __builtin_dwarf_cfa (), \ __builtin_return_address (0)); \ } \ while (0) . . . 85 _Unwind_Reason_Code 86 _Unwind_RaiseException(struct _Unwind_Exception *exc) 87 { 88 struct _Unwind_Context this_context, cur_context; 89 _Unwind_Reason_Code code; 90=20=20=20=20=20=20 91 /* Set up this_context to describe the current stack frame. */ 92 uw_init_context (&this_context); In the below r4 ends up with the __builtin_dwarf_cfa () value: Dump of assembler code for function _Unwind_RaiseException: 0x419a8fd8 <+0>: mflr r0 0x419a8fdc <+4>: stw r31,-148(r1) 0x419a8fe0 <+8>: stw r30,-152(r1) 0x419a8fe4 <+12>: stw r0,4(r1) 0x419a8fe8 <+16>: stwu r1,-2992(r1) 0x419a8fec <+20>: mr r31,r1 . . . 0x419a9094 <+188>: mr r4,r31 0x419a9098 <+192>: mflr r30 0x419a909c <+196>: lwz r5,2996(r31) 0x419a90a0 <+200>: mr r3,r28 0x419a90a4 <+204>: bl 0x419a929c <uw_init_context_1> That r4 ends up holding the stack pointer (r1) value for after it has been decremented. It is not pointing at the boundary with the caller's frame. The .eh_frame information and unwind code is set up for it pointing at the boundary with the caller's frame. So the cfa relative addressing is messed = up for what it actually extracts. Contrast this with gcc/g++ 5.3's TARGET_ARCH=3Dpowerpc64 code where r4 is = made to be at the boundary with the caller's frame: Dump of assembler code for function _Unwind_RaiseException: 0x00000000501cb810 <+0>: mflr r0 0x00000000501cb814 <+4>: stdu r1,-5648(r1) . . . 0x00000000501cb8d0 <+192>: addi r4,r1,5648 0x00000000501cb8d4 <+196>: stw r12,5656(r1) 0x00000000501cb8d8 <+200>: mr r28,r3 0x00000000501cb8dc <+204>: addi r31,r1,2544 0x00000000501cb8e0 <+208>: mr r3,r27 0x00000000501cb8e4 <+212>: addi r29,r1,112 0x00000000501cb8e8 <+216>: bl 0x501cae60 <uw_init_context_1> NOTE: This may in someway be associated with the clang 3.8.0 ABI violation = in how it handles the stack pointer for FreeBSD: TARGET_ARCH=3Dpowerpc is curr= ently using a "red zone", decrementing the stack pointer late, and incrementing t= he stack pointer early compared to the ABI rules. (This is similar to the offi= cial FreeBSD ABI for TARGET_ARCH=3Dpowerpc64.) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207325-8-rfoV1vEDZE>