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]

[Mark Millard]

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
> 
>