From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9434 invoked by alias); 19 Dec 2009 00:35:04 -0000 Received: (qmail 9411 invoked by uid 48); 19 Dec 2009 00:35:03 -0000 Date: Sat, 19 Dec 2009 00:35:00 -0000 Message-ID: <20091219003503.9410.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin* In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "howarth at nitro dot med dot uc dot edu" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2009-q4/txt/msg00095.txt.bz2 ------- Comment #38 from howarth at nitro dot med dot uc dot edu 2009-12-19 00:35 ------- I've confirmed that both the WalkerTest failures and the gcj compiler crashes on java code are eliminated on darwin10 if I duplicate the code for _Unwind_FindEnclosingFunction() as _darwin10_Unwind_FindEnclosingFunction() and export that via the versioned libgcc_ext. So the entire problem is that darwin10's _Unwind_FindEnclosingFunction() is non-functional (and just calls abort()). Fortunately, since FSF gcc builds on darwin10 without compact unwind we still have access to a functional _Unwind_Find_FDE(). We just need to find some approach short of adding a new symbol to libgcc that will provide an alternate means of accessing the code for _Unwind_FindEnclosingFunction() on darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991