Re: [patch] Fix oddity in personality routine

[Jack Howarth <howarth at bromo dot med dot uc dot edu>]

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.
> 
> Andrew.

Andrew,
    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

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. 
     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.
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.
                Jack
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.