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: > > 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> > > Krzysztof Parzyszek changed bug 26519 > What Removed Added > Status REOPENED RESOLVED > Resolution --- FIXED > > Comment # 11 on bug 26519 from Krzysztof Parzyszek > Committed in r282174. > > You are receiving this mail because: > • You reported the bug. === 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: > >> 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 >> 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: >> • You reported the bug. >> >> === >> Mark Millard >> markmi at dsl-only.net > > There is now a code review active for this now, quoting the notice: > >> Comment # 10 on bug 26519 from Krzysztof Parzyszek >> The epilogue part of the fix: https://reviews.llvm.org/D24466 >> >> >> Hopefully there is nothing else missing. >> >> You are receiving this mail because: >> • You reported the bug. > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Sep-10, at 6:23 PM, Mark Millard <markmi at dsl-only.net> wrote: >> >> On 2016-Sep-10, at 10:18 AM, Dimitry Andric <dim at FreeBSD.org> wrote: >> >>> On 06 Sep 2016, at 15:04, Mark Millard <markmi at dsl-only.net> wrote: >>>> >>>> llvm's bugzilla reports that the stack-handling SVR4 ABI violation for TARGET_ARCH=powerpc has been fixed r280705 (likely on trunk)! >>> >>> I merged the upstream fix to projects/clang390-import: >>> >>> https://svnweb.freebsd.org/changeset/base/305686 >>> >>> -Dimitry >> >> Looking at things for this again I've submitted a question to https://llvm.org/bugs/show_bug.cgi?id=26519 asking if the post-amble code's side if things was also adjusted (instead of just the pre-amble/"claim" code side of things). >> >> [I'm not clang/llvm literate so I may have missed interpreted something when I looked.] >> >> 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): >> >>> 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 >> >> 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. >> >> Hopefully I'm just wrong and this was fixed too. >> >> >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F2CD6810-EB95-45D2-8E44-52104F65EA10>