Date: Thu, 22 Sep 2016 10:42:58 -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) [re-fixed in llvm -r282174] Message-ID: <F2CD6810-EB95-45D2-8E44-52104F65EA10@dsl-only.net> In-Reply-To: <DAB74592-5E76-4BD2-9754-44E55DEA0D11@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> <827D7E4C-5719-456E-95D3-A95BBC341E7E@dsl-only.net> <DAB74592-5E76-4BD2-9754-44E55DEA0D11@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Quick top post reporting that the fix for the post-amble code is in = place in llvm -r282174 : > Begin forwarded message: >=20 > From: bugzilla-daemon[ at ]llvm.org > Subject: [Bug 26519] Clang 3.8.0's "Target: = powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI = (SEGV can result) > Date: September 22, 2016 at 10:23:21 AM PDT > To: <markmi[ at ]dsl-only.net> >=20 > Krzysztof Parzyszek changed bug 26519=20 > What Removed Added > Status REOPENED RESOLVED > Resolution --- FIXED >=20 > Comment # 11 on bug 26519 from Krzysztof Parzyszek > Committed in r282174. >=20 > 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-12, at 6:40 PM, Mark Millard <markmi at dsl-only.net> wrote: > On 2016-Sep-10, at 6:56 PM, Mark Millard <markmi at dsl-only.net> = wrote: >=20 >> Quick top post: Krzysztof has re-opened llvm bugzilla 26519 because = the post-amble side of things has not been fixed yet. . . >>=20 >>=20 >>=20 >> 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. >>=20 >> You are receiving this mail because: >> =E2=80=A2 You reported the bug. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > There is now a code review active for this now, quoting the notice: >=20 >> Comment # 10 on bug 26519 from Krzysztof Parzyszek >> The epilogue part of the fix: https://reviews.llvm.org/D24466 >>=20 >>=20 >> Hopefully there is nothing else missing. >>=20 >> You are receiving this mail because: >> =E2=80=A2 You reported the bug. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > 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 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F2CD6810-EB95-45D2-8E44-52104F65EA10>