From owner-freebsd-ppc@freebsd.org Sat Feb 27 23:32:08 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3865AB63B6 for ; Sat, 27 Feb 2016 23:32:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 A76B714CC for ; Sat, 27 Feb 2016 23:32:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14189 invoked from network); 27 Feb 2016 23:31:58 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Feb 2016 23:31:58 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 27 Feb 2016 18:31:53 -0500 (EST) Received: (qmail 31457 invoked from network); 27 Feb 2016 23:31:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 Feb 2016 23:31:53 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 118DD1C43E0; Sat, 27 Feb 2016 15:31:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=powerpc: a bug 207325 update From: Mark Millard In-Reply-To: <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> Date: Sat, 27 Feb 2016 15:31:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain , Roman Divacky , Dimitry Andric X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 23:32:08 -0000 [Top post for dinging the low level problem that directly breaks c++ = exception handling for TARGET_ARCH=3Dpowerpc for clang 3.8.0 generated = code.] I've tracked down the c++ exception problem for TARGET_ARCH=3Dpowerpc = via clang 3.8.0: misbehavior of clang 3.8.0 code generation for = __builtin_dwarf_cfa () as used 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=09 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 supplied = to uw_init_context_1: 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 That r4 ends up holding the stack pointer value for after it has been = decremented. r4 is not pointing at the boundary with the caller's frame. The .eh_frame information and unwind code is set up for 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 NOTE: The powerpc (32-bit) issue may in some way be associated with the = clang 3.8.0 powerpc ABI violation in how it handles the stack pointer = for FreeBSD: TARGET_ARCH=3Dpowerpc is currently using a "red zone", = decrementing the stack pointer late, and incrementing the stack pointer = early compared to the FreeBSD ABI rules. (This is similar to the = official FreeBSD ABI for TARGET_ARCH=3Dpowerpc64.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-26, at 3:26 PM, Mark Millard wrote: >=20 > On 2016-Feb-19, at 11:37 AM, Mark Millard = wrote: >=20 >> The following program does not work for my example = TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 environments for = buildworld based on projects/clang380-import -r205601: >>=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} // same result without & >> return 0; >> } >>=20 >> The details vary for what happens and what compiler is in use. >>=20 >> TARGET_ARCH=3Dpowerpc with clang 3.8.0: SEGV >>=20 >> TARGET_ARCH=3Dpowerpc64 with devel/powerpc64-gcc: unbouded loop in = _Unwind_RaiseException >>=20 >> For the powerpc64 context: g++49 can be used to show the problem as = well: >>=20 >> Using g++49's a.out gets the same unbounded loop result for: >>=20 >> # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic = exception_test.cpp = =20 >>=20 >> But the a.out works fine for a normal g++49 header/library usage: >>=20 >> # g++49 -g -Wall -pedantic exception_test.cpp >> # ./a.out >> #=20 >>=20 >>=20 >>=20 >> (These were noticed by trying to build and use kyua to run the = /usr/tests material in tehse enviroments.) >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > [Note: The _Unwind_RaiseException involved below was compiled by clang = 3.8.0 during buildworld. So clang generated the .eh_frame information = involved.] >=20 > In the TARGET_ARCH=3Dpowerpc operation there are a sequence of 2 = errors, the 2nd of which gets the SEGV: >=20 > A) The catch clause is rejected/ignored so std::terminate is called >=20 > B) During the std::terminate related execution the SEGV happens. >=20 > (A) is the more fundamental issue. >=20 > I have found the following mismatch between some powerpc code = generated and the .eh_frame information generated by clang 3.8.0 for the = TARGET_ARCH=3Dpowerpc context. (Using objdump and dwarfdump notation = below, no relocations.) The specific example need not be directly = involved in (A) or (B) but is inaccurate .eh_frame generation either = way. >=20 >> 00007fd8 <_Unwind_RaiseException> mflr r0 >> 00007fdc <_Unwind_RaiseException+0x4> stw r31,-148(r1) >> 00007fe0 <_Unwind_RaiseException+0x8> stw r30,-152(r1) >> 00007fe4 <_Unwind_RaiseException+0xc> stw r0,4(r1) >> 00007fe8 <_Unwind_RaiseException+0x10> stwu r1,-2992(r1) >> 00007fec <_Unwind_RaiseException+0x14> mr r31,r1 >> 00007ff0 <_Unwind_RaiseException+0x18> mfcr r12 >> . . . >> 0000827c <_Unwind_RaiseException+0x2a4> lwz r14,2776(r31) >> 00008280 <_Unwind_RaiseException+0x2a8> addi r1,r1,2992 >> 00008284 <_Unwind_RaiseException+0x2ac> lwz r0,4(r1) >> 00008288 <_Unwind_RaiseException+0x2b0> lwz r31,-148(r1) >> 0000828c <_Unwind_RaiseException+0x2b4> lwz r30,-152(r1) >> 00008290 <_Unwind_RaiseException+0x2b8> mtlr r0 >> 00008294 <_Unwind_RaiseException+0x2bc> blr >> 00008298 <_Unwind_RaiseException+0x2c0> bl 0001eccc >=20 > The .eh_frame information shown by dwarfdump (see later below) shows = off cfa=3D2992(r31) over the range starting at 0x00007ff0 but 0x828c to = 0x8298 comes after R31 is returned to its old value. (The range goes up = to 0x0000829c, which is the start of the next block of addresses.) >=20 > is just wrong at 0000828c and later above. >=20 > (I'm not going to make claims here about 0x00007ff0 below listing both = and or how such is = handled. But it would seem that cfa=3D?(r31)'s interpretation would need = to ignore any prior or same line r31=3D?(cfa). Either way it is = generally wrong once cfa itself is inaccurate, as it is at 0000828c.) >=20 > The dwarfdump -v -v -F material for this is: >=20 >> < 0><0x00007fd8:0x0000829c><> >> 0x00007fd8: =20 >> 0x00007fec: =20 >> 0x00007ff0: =20 >> fde section offset 692 0x000002b4 cie offset for fde: 696 0x000002b8 >> 0 DW_CFA_advance_loc 20 (5 * 4) >> 1 DW_CFA_def_cfa_offset 2992 >> 4 DW_CFA_offset r31 -148 (37 * -4) >> 6 DW_CFA_offset r30 -152 (38 * -4) >> 8 DW_CFA_offset_extended_sf r65 4 (-1 * -4) >> 11 DW_CFA_advance_loc 4 (1 * 4) >> 12 DW_CFA_def_cfa_register r31 >> 14 DW_CFA_offset r14 -216 (54 * -4) >> 16 DW_CFA_offset r15 -212 (53 * -4) >> 18 DW_CFA_offset r16 -208 (52 * -4) >> 20 DW_CFA_offset r17 -204 (51 * -4) >> 22 DW_CFA_offset r18 -200 (50 * -4) >> 24 DW_CFA_offset r19 -196 (49 * -4) >> 26 DW_CFA_offset r20 -192 (48 * -4) >> 28 DW_CFA_offset r21 -188 (47 * -4) >> 30 DW_CFA_offset r22 -184 (46 * -4) >> 32 DW_CFA_offset r23 -180 (45 * -4) >> 34 DW_CFA_offset r24 -176 (44 * -4) >> 36 DW_CFA_offset r25 -172 (43 * -4) >> 38 DW_CFA_offset r26 -168 (42 * -4) >> 40 DW_CFA_offset r27 -164 (41 * -4) >> 42 DW_CFA_offset r28 -160 (40 * -4) >> 44 DW_CFA_offset r29 -156 (39 * -4) >> 46 DW_CFA_offset r30 -152 (38 * -4) >> 48 DW_CFA_offset r31 -148 (37 * -4) >> 50 DW_CFA_offset r46 -144 (36 * -4) >> 52 DW_CFA_offset r47 -136 (34 * -4) >> 54 DW_CFA_offset r48 -128 (32 * -4) >> 56 DW_CFA_offset r49 -120 (30 * -4) >> 58 DW_CFA_offset r50 -112 (28 * -4) >> 60 DW_CFA_offset r51 -104 (26 * -4) >> 62 DW_CFA_offset r52 -96 (24 * -4) >> 64 DW_CFA_offset r53 -88 (22 * -4) >> 66 DW_CFA_offset r54 -80 (20 * -4) >> 68 DW_CFA_offset r55 -72 (18 * -4) >> 70 DW_CFA_offset r56 -64 (16 * -4) >> 72 DW_CFA_offset r57 -56 (14 * -4) >> 74 DW_CFA_offset r58 -48 (12 * -4) >> 76 DW_CFA_offset r59 -40 (10 * -4) >> 78 DW_CFA_offset r60 -32 (8 * -4) >> 80 DW_CFA_offset r61 -24 (6 * -4) >> 82 DW_CFA_offset r62 -16 (4 * -4) >> 84 DW_CFA_offset r63 -8 (2 * -4) >> 86 DW_CFA_nop >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20