Skip site navigation (1)Skip section navigation (2)
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>