From owner-freebsd-toolchain@freebsd.org Sat May 6 05:13:16 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 54140D603FC for ; Sat, 6 May 2017 05:13:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (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 17CD6E5A for ; Sat, 6 May 2017 05:13:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19162 invoked from network); 6 May 2017 05:13:14 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 May 2017 05:13:14 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 06 May 2017 01:13:14 -0400 (EDT) Received: (qmail 6315 invoked from network); 6 May 2017 05:13:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 May 2017 05:13:13 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 240A6EC7DD3; Fri, 5 May 2017 22:13:13 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: llvm FreeBSD powerpc ABI target bug fix: Re: [Bug 26519] Clang 4.0.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result) Date: Fri, 5 May 2017 22:13:12 -0700 References: <0103401A-CEEA-4992-A45E-E60EA151119B@dsl-only.net> <893ECA11-7C80-4D24-A496-92ADC7978A07@FreeBSD.org> <8F708AD1-055E-41BD-BD92-6A87C5FBAA60@dsl-only.net> <78CD5050-2B2B-4213-AF11-7EF744F608B2@dsl-only.net> To: FreeBSD Toolchain , FreeBSD PowerPC ML In-Reply-To: Message-Id: 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: Sat, 06 May 2017 05:13:16 -0000 On 2017-May-5, at 6:11 PM, Mark Millard wrote: > On 2017-May-5, at 1:22 AM, Mark Millard wrote: >=20 >> On 2017-May-5, at 12:45 AM, Mark Millard = wrote: >>=20 >>> On 2017-May-4, at 2:41 PM, Dimitry Andric = wrote: >>>=20 >>>> . . . >>>> Thanks for the notice. I have merged the upstream fix into head in >>>> r317810, and I will MFC it after a few days. >>>=20 >>> I now have an old PowerMac running: >>>=20 >>> # uname -paKU >>> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc 1200030 1200030 >>>=20 >>> where buildworld was via clang 4 (an amd64->powerpc >>> cross build). Even the classic tiny program that >>> previously showed C++ exception handling was broken >>> and would crash the program now works when >>> re-compiled and re-linked. Commands that were >>> previous broken now work. >=20 > I messed up and accidentally installed the > gcc 4.2.1 world that I had also built. This > is why C++ exceptions appeared to be working > for powerpc. >=20 > Both TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 > have C++ exceptions still messed up. >=20 >=20 >>> . . . >>>=20 >>> For the gcc 4.2.1 based kernel boot I have >>> had one odd fatal kernel trap (0x903a64a, >>> "unknown") where the lr showed 0x907f . It >>> reported being stopped at: >>>=20 >>> ffs_truncate+0x1080 >>>=20 >>> It appears that "call doadump" worked but >>> I've not looked at what was put in >>> /var/crash/ . >>=20 >> If I leave the PowerMac idle running: >>=20 >> # uname -paKU >> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc = powerpc 1200030 1200030 >>=20 >> it eventually gets the same ffs_truncate-tied fatal >> kernel trap, with the same odd lr and the like. >>=20 >> So, while I cannot directly cause the problem >> at a specific time, the problem is repeatable. >>=20 >> I did not build the kernel with a so-called >> "red-zone" to work around any stack-operation >> ordering problems that might still be around. >> But I do not know that such is involved here. >> It may be a while before I manage to get that >> much of an analysis done. >=20 > The ffs_truncate issue is odd: >=20 > A) It was gcc 4.2.1 based for both kernel and world. > B) I built a gcc 4.2.1 based debug kernel and > installed it but that does not get the problem. >=20 > I sam trying the gcc 4.2.1 debug kernel with the > system clang 4 world now and will later switch > to the gcc 4.2.1 non-debug kernel to see what > happens. >=20 > But being a pure gcc 4.2.1 environment originally > suggests that the ffs_truncate issue is not > clang-toolchain related. I found a bad (old) kernel module in /boot/kernel/ and eliminating it appears to have removed the ffs_truncate problem. And even more good news: buildworld buildkernel makes extensive use of signals and its failure is how I discovered the original stack handling problems for powerpc (the ABI violations). I used to have to patch in so-called "red zone" handling to avoid the issue. No more: a running a kernel that was built without a "red zone" and running a world based on clang now allows buildworld buildkernel to complete just fine: no evidence of ABI violations in the world code that is executed. Going the other direction: I've conformed that clang still generates C++ programs that can not handle thrown exceptions. Both powerpc and powerpc64 are this way. The only other area with an issue that I know of is the exec /sbin/init failure that prevents using the clang based kernel for powerpc. (This is based on the system binutils for powerpc and devel/*binutils for powerpc64 instead of lld and such. lld has its own problems for these targets.) I already build and run powerpc64 kernels built by clang. That has been true for a while. =3D=3D=3D Mark Millard markmi at dsl-only.net