Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 06 Mar 2016 13:58:17 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 207736] clang 3.8.0/powerpc's _Unwind_RaiseException code generation has messed up r31 (frame pointer) save/restore code (SEGV's can result)
Message-ID:  <bug-207736-8-nGg1qoxNvI@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-207736-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-207736-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207736

--- Comment #1 from Mark Millard <markmi@dsl-only.net> ---
I compiled a .o for TARGET_ARCH=3Dpowerpc64 via letting "buildworld" get as=
 far
as it could and the resultant .o produced has the same sort of
r31/frame-pointer problem as powerpc for _Unwind_RaiseException: The problem
DOES occur for powerpc64.

A) r31 is stored twice to the same location, with the 2nd store destroying =
the
frame-pointer value that is supposed to be saved and restored for the calle=
r.

B) r31 is restored twice from the same location.

The FreeBSD TARGET_ARCH=3Dpowerpc64 does officially use a stack red-zone on=
 the
low-address side with officially "late" decrement and "early" increment (AIX
like). Relative to this:

A) each r31 store is on a different side of the "late" r1 decrement

and

B) each r31 restore is on a different side of the "early" r1 increment

TARGET_ARCH=3Dpowerpc gets that same relationships but the late r1 decremen=
t and
early r1 increment are SVR4 ABI violations: SVR4'sABI does not require a
"red-zone" on the low-address side of the stack.

(To get as far as I have for powerpc "buildworld" I had to add signal red-z=
one
handling to my personal FreeBSD builds.)

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207736-8-nGg1qoxNvI>