Re: [patch] Fix oddity in personality routine

Jack Howarth wrote:
> On Fri, Dec 04, 2009 at 09:44:29AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> Using the patch...
>> Let's see the compile time output, when the executables were linked.
>>
>>> This is interesting since on x86_64-apple-darwin10, we have been failing...
>>>
>>> FAIL: WalkerTest execution - source compiled test
>>> FAIL: WalkerTest -findirect-dispatch execution - source compiled test
>>> FAIL: WalkerTest -O3 execution - source compiled test
>>> FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test
>> Since when?  You didn't mention this before.

>     I believe we have been seeing the additional WalkerTest
> failures under darwin10 ever since gcc trunk was fixed so
> that darwin10 built with stack execution like darwin9...
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html

OK.  I'm pretty sure this is a different failure.

> However this may all be a red herring because x86_64-apple-darwin9
> (which doesn't show these WalkerTest failures) shows the
> same issue with gcj crashing when compiling java code.
>      I suspect we may have a layered problem here and need
> to work through each section. This weekend, I do some additional
> builds to verify that the crash debugs to the same locations
> in both darwin9 and darwin10 with and without the proposed
> patch to pass -Wl,-allow_stack_execute on GCJLINK.

Right.

>      The WalkerTest failures in darwin10 may be orthogonal to
> the issue of gcj crashing since they don't occur in darwin9
> and darwin9 has the gcj issue as well. I'll do some builds this
> weekend to verify that...
> 
> 1) x86_64-apple-darwin9 still passes the WalkerTests
> 2) x86_64-apple-darwin9 and x86_64-apple-darwin10 both backtrace
> to the same place when gcj crashes compiling java code.
> 3) When the GCJLINK to patched to always pass -Wl,-allow_stack_execute
> that the backtrace moves to the same place in both x86_64-apple-darwin9
> and x86_64-apple-darwin10.

Do you see the same page fault once -Wl,-allow_stack_execute is used?
If not, this one is fixed, and we can look at the unwinder fproblem.

> 4) I'll also back out the libgcc-ext patch completely and verify that
> x86_64-apple-darwin9 crashes at the same locations for step 2 and 3.
> This will verify that the system unwinder and the FSF libgcc unwinder
> both behave the same in these gcj crashes.

> ps As I mentioned before, darwin10 uses an unwinder in libSystem which
> is derived from that in gcc 4.2.1. Also, since the libgcc_ext patch
> went into gcc trunk, darwin9 also links in the system libgcc_s.10.5
> before the FSF libgcc_s so that it also now uses the system unwinder
> (from libgcc). However note that thse gcj crashes predate all of this.
> I have verified that they go as far back as gcc 4.3.4.

OK.  So, we may have just one bug left rather than two.  Here's hoping.

Andrew.