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 > > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
