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=207325 --- Comment #6 from Mark Millard <markmi@dsl-only.net> --- I've tracked this down to misbehavior of clang 3.8.0 for __builtin_dwarf_cfa () for TARGET_ARCH=powerpc 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 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=powerpc64 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=powerpc is currently using a "red zone", decrementing the stack pointer late, and incrementing the stack pointer early compared to the ABI rules. (This is similar to the official FreeBSD ABI for TARGET_ARCH=powerpc64.) -- 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>