From owner-freebsd-toolchain@freebsd.org Thu May 25 22:06:41 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 5D69ED82EE4 for ; Thu, 25 May 2017 22:06:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (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 220D21BB3 for ; Thu, 25 May 2017 22:06:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12676 invoked from network); 25 May 2017 21:59:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 May 2017 21:59:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 25 May 2017 17:59:19 -0400 (EDT) Received: (qmail 10415 invoked from network); 25 May 2017 21:59:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 May 2017 21:59:19 -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 11BB2EC805D; Thu, 25 May 2017 14:59:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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) From: Mark Millard In-Reply-To: <408D3509-3D62-4413-986B-6C1171FB6138@dsl-only.net> Date: Thu, 25 May 2017 14:59:18 -0700 Cc: Roman Divacky , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <0103401A-CEEA-4992-A45E-E60EA151119B@dsl-only.net> <893ECA11-7C80-4D24-A496-92ADC7978A07@FreeBSD.org> <408D3509-3D62-4413-986B-6C1171FB6138@dsl-only.net> To: Dimitry Andric 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 22:06:41 -0000 [Top post of question with older material listed after for reference.] Is llvm bugzilla's latest 26519 fix going to make it into release/11.1.0 ? This fixes the last known stack handling ABI violation for targeting powerpc FreeBSD (32-bit). (For both powerpc64 and powerpc handling thrown C++ exceptions still needs work but the above does make the rest of buildworld operational for TARGET_ARCH=3Dpowerpc --as far as my basic testing goes anyway.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-May-17, at 3:22 PM, Mark Millard wrote: I got a notice this morning of the latest fix for covering the TARGET_ARCH=3Dpowerpc stack-handling issues for llvm bugzilla 26519: > Comment # 33 on bug 26519 from Krzysztof Parzyszek > The fix has been committed in master in r303257. >=20 > I opened PR33070 to request merging it into 4.0.1. >=20 > You are receiving this mail because: > =E2=80=A2 You reported the bug. I've been using a version of the patch for some time and for buildworld it appears that with it powerpc and powerpc64 have a similar status: the one known area not working is handling of thrown C++ exceptions --for example the required dwarf information is incomplete so programs crash. (I have one powerpc64 patch in use that is not applied upstream or in FreeBSD that is essential for the powerpc64 status. See the later side notes for the tiny patch.) For buildkernel there is a difference for TARGET_ARCH=3Dpowerpc vs. TARGET_ARCH=3Dpowerpc64 : A) powerpc46 works for building and running the kernel and world on the old G5 PowerMacs. B) powerpc FreeBSD on the same machines fails at the /sbin/init attempt and then gets an alignment exception. (I've not tried a G4 or G3 yet.) As of yet I've no clue why (B) is an issue. Side notes: Note 0: The patch I was given a fair time ago that is required for TARGET_ARCH=3Dpowerpc64 is: # svnlite diff /usr/src/contrib/llvm/tools/ Index: /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp (revision = 317820) +++ /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp (working copy) @@ -1070,7 +1070,8 @@ } PPC64TargetInfo::PPC64TargetInfo() { - PltRel =3D GotRel =3D R_PPC64_GLOB_DAT; + GotRel =3D R_PPC64_GLOB_DAT; + PltRel =3D R_PPC64_JMP_SLOT; RelativeRel =3D R_PPC64_RELATIVE; GotEntrySize =3D 8; (Thanks to Roman Divacky.) Note 1: While a pure gcc 4.2.1 buildworld buildkernel with a debug kernel is working for booting and using, a production style kernel gets occasional panics on the old G5 PowerMacs. (The powerpc64 builds work fine on the same machines.) (I've not tried any G4's or a G3 yet.) It also appears that small changes in memory layout details (from trying to get better evidence) change the behavior/failure-mode/ details. I do not expect to find out what is going on any time soon. The same problems existed when buildworld was via clang 4. A kernel from a clang buildkernel does not get far enough for me to see what it would do for the issue. As this issue is more fundamental to general operation it has been getting much of my FreeBSD time. =3D=3D=3D Mark Millard markmi at dsl-only.net