On 2016-Mar-5, at 5:13 PM, Mark Millard <[email protected]> wrote: > > I have submitted FreeBSD bug 207732: > > libgcc_s .eh_frame handling messes up interpreting powerpc/powerpc64 frame > pointer register use produced by clang 3.8.0 > > In essence clang++ 3.8.0 generates Frame Pointer Register based code (r31 in > addition to the r1 stack pointer) that g++ 4.2.1/4.9/5.3 (normally) do not > and so the clang++ 3.8.0 code ends up touching an error in libgcc_s > interpreting .eh_frame information for C++ exception handling that gcc 4.2.1 > and the like side step by not using such a Frame Pointer register. > > Note: The context for libgcc_s was a clang 3.8.0 based buildworld. A gcc > buildworld does not involve such a Frame Pointer Register. > > I do not know if any TARGET_ARCH's other than powerpc/powerpc64 also generate > such Frame Pointer Register like code and so might touch the same error. > > > === > Mark Millard > markmi at dsl-only.net
With the other errors identified and reported for .eh_frame and C++ exception handling for powerpc it is getting harder to tell if a problem is a new problem or a consequence of the other ones. (Various problems have no work around yet to avoid them.) This turned out to be a consequence of other problems. Such was easier to discover once I induced gcc 4.2.1 to generate some example code with r31 in use as a frame pointer. (I used alloca and default optimization.) Observing the result's behavior and the .eh_frame output indicated I'd originally misinterpreted where the earliest problem was in the clang 3.8.0 context. === 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]"
