From owner-freebsd-toolchain@freebsd.org Thu May 25 04:03:55 2017 Return-Path: Delivered-To: freebsd-toolchain@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 BFD7FD8179B for ; Thu, 25 May 2017 04:03:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 8602A19D6 for ; Thu, 25 May 2017 04:03:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29448 invoked from network); 25 May 2017 04:03:53 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 May 2017 04:03:53 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 25 May 2017 00:03:53 -0400 (EDT) Received: (qmail 8168 invoked from network); 25 May 2017 04:03:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 May 2017 04:03:53 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CFE10EC78CC; Wed, 24 May 2017 21:03:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PowerPC64 C++ exceptions with clang/llvm From: Mark Millard In-Reply-To: <20170524113441.GA58092@vlakno.cz> Date: Wed, 24 May 2017 21:03:52 -0700 Cc: FreeBSD Toolchain , freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <74D091B2-71CD-42DE-8C1E-8E0BDED1EAFD@dsl-only.net> References: <20170524113441.GA58092@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 04:03:55 -0000 [So far I've been unable to replicate dwarfump reporting anything near "0x94 00 00 00 01 00 01 02 ed 14 1b". The compiled code still gets SIGSEGV: it is only the low level detail that I'm noting as different. Roman has more information from me than I show here.] On 2017-May-24, at 4:34 AM, Roman Divacky wrote: > Hi, >=20 > Currently C++ exceptions don't work on PowerPC64 when compiled with = clang. I > looked at why and discovered the following. >=20 > With the default gcc unwinder and libstdc++ this simple test program: >=20 > #include >=20 > int main() > { > try { > std::cout << "Before\n"; > throw std::exception(); > std::cout << "After\n"; > } catch (...) { > std::cout << "Exception\n"; > } > } >=20 > segfaults right after printing "Before\n". This is because the = .eh_frame is corrupted and > the personality relocation is wrong: >=20 > < 1> version 1 > cie section offset 56 0x00000038 > augmentation zPLR > code_alignment_factor 4 > data_alignment_factor -8 > return_address_register 65 > eh aug data len 0xb bytes 0x94 00 00 00 01 00 01 02 ed 14 1b=20 So far I'm unable to replicate producing anything like the "large one" as I'll call it. I get things like: # clang++ -std=3Dc++11 exception_test_dots.cpp # dwarfdump -v -v -F a.out | more .eh_frame . . . cie: < 0> version 1 . . . eh aug data len 0xb bytes 0x94 00 00 00 00 00 01 03 45 14 1b=20 . . . (No cia<1> at all.) and like: # clang++ -B /usr/local/bin/ -std=3Dc++11 exception_test_dots.cpp # dwarfdump -v -v -F a.out | more .eh_frame . . . cie: < 0> version 1 . . . < 1> version 1 . . . eh aug data len 0xb bytes 0x94 00 00 00 00 00 01 f1 1d 14 1b=20 . . . My context is head -r317820 on a system built with the system clang without building gcc 4.2.1 materials. # uname -paKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc64 1200030 1200030 # ld --version GNU ld 2.17.50 [FreeBSD] 2007-07-03 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms = of the GNU General Public License. This program has absolutely no = warranty. # /usr/local/bin/ld --version GNU ld (GNU Binutils) 2.27 Copyright (C) 2016 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms = of the GNU General Public License version 3 or (at your option) a later = version. This program has absolutely no warranty. (I have avoided 2.28 so far because of the "return code" consequences on the likes of aarch64.) I've tried variations like omitting -std=3Dc++11. So far I've not found a way to get near: "0x94 00 00 00 01 00 01 02 ed 14 1b" but all the experiments get SIGSEGV when I run the produced program. (I do not have a gcc 4.2.1 build around and so do not have libstdc++ on powerpc64.) > bytes of initial instructions 3 > cie length 28 > initial instructions > 0 DW_CFA_def_cfa r1 0 >=20 > the personality relocation is "00 00 00 01 00 01 02 ed" encoded as pc = relative. The program segfaults > because this address is wrong. The 33rd bit is incorrect, the real = address should be "00 00 00 00 00 01 02 ed". > The same problem applies for LDSA encoding. Both personality and LDSA = relocations are produced by CFI instructions > in the assembler source code. >=20 > I verified this theory by hacking the gcc unwinder and libsupc++ &=3D = the address with 0xffffffff; and that made > the application work. (the full patch can be found at = http://www.vlakno.cz/~rdivacky/ppc64.exceptions.hack.patch). >=20 > I checked why this relocation is wrong and it turns out it's our old = in-tree ld that (wrongly) produces this. > Our old gcc does not use CFI to produce these and hardcodes the CIE = manually and produces correct address. And for > some reason ld is fine with that. >=20 > When I compile and assemble the above source code using clang++ and = only use newer ld linker from ports the resulting > binary is correct and works as expected. >=20 > So this is a bug in our in-tree ld linker. I don't know why ld has = this bug but given Mark Millard's report of ld > being broken for other stuff (kernel iirc) I am not going to bother = trying to fix it. I suspect it might be related > to comdats but I didn't really investigate. >=20 > I didn't try the situation with the LLVM unwinder and libcxxrt, but I = hope it might be the same. Side note: Why I'm at head -r317820 . . . For TARGET_ARCH=3Dpowerpc I've got a periodic panic after booting for which changing the memory layout even a little bit seems to stop the panic. (Something less obvious may still be wrong.) The panic can take minutes but usually is more like hours. Even attempting to add small amounts of debug code tends to make the problem invisible. Thus a binary search for versions is not in the cards for now. So I've been focusing on trying for evidence about what leads to the panic and I've not been updating any of the FreeBSD environments that I have around. =3D=3D=3D Mark Millard markmi at dsl-only.net