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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207736 --- Comment #1 from Mark Millard <markmi@dsl-only.net> --- I compiled a .o for TARGET_ARCH=powerpc64 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 caller. B) r31 is restored twice from the same location. The FreeBSD TARGET_ARCH=powerpc64 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=powerpc gets that same relationships but the late r1 decrement 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-zone handling to my personal FreeBSD builds.) -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207736-8-nGg1qoxNvI>