From owner-freebsd-toolchain@freebsd.org Sun Sep 11 01:56:35 2016 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 A2B3EBD27AC for ; Sun, 11 Sep 2016 01:56:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-180.reflexion.net [208.70.211.180]) (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 4E999A0C for ; Sun, 11 Sep 2016 01:56:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24135 invoked from network); 11 Sep 2016 01:57:21 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Sep 2016 01:57:21 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sat, 10 Sep 2016 21:56:24 -0400 (EDT) Received: (qmail 22751 invoked from network); 11 Sep 2016 01:56:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2016 01:56:24 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B49AEC8B81; Sat, 10 Sep 2016 18:56:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: From llvm: Fwd: [Bug 26519] Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result) [fixed in llvm -r280705] From: Mark Millard In-Reply-To: Date: Sat, 10 Sep 2016 18:56:31 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <827D7E4C-5719-456E-95D3-A95BBC341E7E@dsl-only.net> References: <08136189-299F-4BD6-9E49-8D39A8913D62@dsl-only.net> <0E2783E3-277F-47F1-B696-46FCFF0DB0F1@dsl-only.net> <09E211AC-6245-4A89-94DE-225A5EBA1FD2@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3124) 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: Sun, 11 Sep 2016 01:56:35 -0000 Quick top post: Krzysztof has re-opened llvm bugzilla 26519 because the = post-amble side of things has not been fixed yet. . . Krzysztof Parzyszek changed bug 26519=20 What Removed Added Status RESOLVED REOPENED Resolution FIXED --- Comment # 9 on bug 26519 from Krzysztof Parzyszek The post-amble has not been fixed. You are receiving this mail because: =E2=80=A2 You reported the bug. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Sep-10, at 6:23 PM, Mark Millard wrote: >=20 > On 2016-Sep-10, at 10:18 AM, Dimitry Andric = wrote: >=20 >> On 06 Sep 2016, at 15:04, Mark Millard = wrote: >>>=20 >>> llvm's bugzilla reports that the stack-handling SVR4 ABI violation = for TARGET_ARCH=3Dpowerpc has been fixed r280705 (likely on trunk)! >>=20 >> I merged the upstream fix to projects/clang390-import: >>=20 >> https://svnweb.freebsd.org/changeset/base/305686 >>=20 >> -Dimitry >=20 > Looking at things for this again I've submitted a question to = https://llvm.org/bugs/show_bug.cgi?id=3D26519 asking if the post-amble = code's side if things was also adjusted (instead of just the = pre-amble/"claim" code side of things). >=20 > [I'm not clang/llvm literate so I may have missed interpreted = something when I looked.] >=20 > My original submittal also noted the stack pointer adjustment-timing = problem existed on the post-amble side in 3.8.0's code generation (when = removing the frame from the stack): >=20 >> 0x1801b8c : lwz r30,24(r31) >> 0x1801b90 : lwz r29,20(r31) >> 0x1801b94 : lwz r28,16(r31) >> 0x1801b98 : lwz r27,12(r31) >> 0x1801b9c : lwz r26,8(r31) >> 0x1801ba0 : addi r1,r1,32 # Stack = pointer adjusted first >> 0x1801ba4 : lwz r0,4(r1) >> 0x1801ba8 : lwz r31,-4(r1) # Then Frame = Pointer load happens >> # "outside" the new = stack range. >> 0x1801bac : mtlr r0 >> 0x1801bb0 : blr >=20 > If such code can still be generated there would still be a time frame = needing a red-zone to protect stack the contents from signals. >=20 > Hopefully I'm just wrong and this was fixed too. >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20