Date: Sat, 10 Sep 2016 18:23:23 -0700 From: Mark Millard <markmi@dsl-only.net> To: Dimitry Andric <dim@FreeBSD.org>, Krzysztof Parzyszek <kristof@swissmail.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: <DB6E7EB1-250B-43BC-B3F2-860BE9D96616@dsl-only.net> In-Reply-To: <09E211AC-6245-4A89-94DE-225A5EBA1FD2@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=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 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). [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. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DB6E7EB1-250B-43BC-B3F2-860BE9D96616>