207732 submitted: libgcc_s .eh_frame handling messes up interpreting powerpc/powerpc64 frame pointer register use produced by clang 3.8.0 [I was wrong]

[Mark Millard]

On 2016-Mar-5, at 5:13 PM, Mark Millard <markmi at dsl-only.net> 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