Date: Sat, 10 Sep 2016 18:56:31 -0700 From: Mark Millard <markmi@dsl-only.net> To: Dimitry Andric <dim@FreeBSD.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> 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] Message-ID: <827D7E4C-5719-456E-95D3-A95BBC341E7E@dsl-only.net> In-Reply-To: <DB6E7EB1-250B-43BC-B3F2-860BE9D96616@dsl-only.net> References: <bug-26519-7604-VMzNnQls1g@http.llvm.org/bugs/> <08136189-299F-4BD6-9E49-8D39A8913D62@dsl-only.net> <0E2783E3-277F-47F1-B696-46FCFF0DB0F1@dsl-only.net> <09E211AC-6245-4A89-94DE-225A5EBA1FD2@FreeBSD.org> <DB6E7EB1-250B-43BC-B3F2-860BE9D96616@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <markmi at dsl-only.net> wrote: >=20 > On 2016-Sep-10, at 10:18 AM, Dimitry Andric <dim at FreeBSD.org> = wrote: >=20 >> On 06 Sep 2016, at 15:04, Mark Millard <markmi at dsl-only.net> = 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 <Buf_AddBytes+104>: lwz r30,24(r31) >> 0x1801b90 <Buf_AddBytes+108>: lwz r29,20(r31) >> 0x1801b94 <Buf_AddBytes+112>: lwz r28,16(r31) >> 0x1801b98 <Buf_AddBytes+116>: lwz r27,12(r31) >> 0x1801b9c <Buf_AddBytes+120>: lwz r26,8(r31) >> 0x1801ba0 <Buf_AddBytes+124>: addi r1,r1,32 # Stack = pointer adjusted first >> 0x1801ba4 <Buf_AddBytes+128>: lwz r0,4(r1) >> 0x1801ba8 <Buf_AddBytes+132>: lwz r31,-4(r1) # Then Frame = Pointer load happens >> # "outside" the new = stack range. >> 0x1801bac <Buf_AddBytes+136>: mtlr r0 >> 0x1801bb0 <Buf_AddBytes+140>: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?827D7E4C-5719-456E-95D3-A95BBC341E7E>