From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15412 invoked by alias); 19 Dec 2009 13:47:34 -0000 Received: (qmail 15404 invoked by uid 22791); 19 Dec 2009 13:47:33 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from bromo.med.uc.edu (HELO bromo.med.uc.edu) (129.137.3.146) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sat, 19 Dec 2009 13:47:28 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id A8ED7400007; Sat, 19 Dec 2009 08:47:25 -0500 (EST) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id nBJDlPbM029664; Sat, 19 Dec 2009 08:47:25 -0500 Date: Sat, 19 Dec 2009 13:47:00 -0000 From: Jack Howarth To: Andrew Haley Cc: java@gcc.gnu.org Subject: Re: _Unwind_FindEnclosingFunction vs darwin Message-ID: <20091219134725.GA29636@bromo.med.uc.edu> References: <20091218144617.GA21353@bromo.med.uc.edu> <4B2B9934.7010205@redhat.com> <20091218204147.GA23604@bromo.med.uc.edu> <4B2CB00D.5070405@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2CB00D.5070405@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00045.txt.bz2 On Sat, Dec 19, 2009 at 10:50:53AM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Fri, Dec 18, 2009 at 03:01:08PM +0000, Andrew Haley wrote: > >> _Unwind_Find_FDE is a standard function. Does Darwin support that? > >> > > > > Andrew, > > I believe we do have _Unwind_Find_FDE on darwin10 but it > > is only functional if compact unwind information isn't used. > > This is currently the case in gcc trunk since I disabled > > the darwin10 linker's default of using compact unwind info > > to avoid issues with the new epilog unwind info on the > > darwin10 linker. > > Shouldn't we be able to add something like... > > > > void * > > darwin10_Unwind_FindEnclosingFunction (void *pc) > > { > > struct dwarf_eh_bases bases; > > const struct dwarf_fde *fde = _Unwind_Find_FDE (pc-1, &bases); > > if (fde) > > return bases.func; > > else > > return NULL; > > } > > > > and use... > > > > #undefine _Unwind_FindEnclosingFunction(PC) > > #define _Unwind_FindEnclosingFunction(PC) darwin10_Unwind_FindEnclosingFunction(PC) > > > > to avoid the system _Unwind_FindEnclosingFunction() on darwin10? > > Sure. > > > I assume that darwin10_Unwind_FindEnclosingFunction code would have to go into > > libjava/darwin.cc. However, I am unclear where to place... > > > > #undefine _Unwind_FindEnclosingFunction(PC) > > #define _Unwind_FindEnclosingFunction(PC) darwin10_Unwind_FindEnclosingFunction(PC) > > It can either go in include/config.h if it's autoconf'd or perhaps in > one of the libgcj include files. > > The easiest thing would be to add > > #ifdef USING_DARWIN_CRT > #undefine _Unwind_FindEnclosingFunction(PC) > #define _Unwind_FindEnclosingFunction(PC) darwin10_Unwind_FindEnclosingFunction(PC) > #endif > > to include/posix.h. > > Please make sure that darwin10_Unwind_FindEnclosingFunction is not exported from > anywhere. I'd just declare it static inline in include/posix.h. > > Andrew. Andrew, The bigger question is were do we put the actual code for darwin10_Unwind_FindEnclosingFunction() such that libgcj can access it. We do have access to libgcc_ext now in gcc 4.5 for extra symbols but I am unclear if a given target can add its own symbols to libgcc_s. Jack