From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25828 invoked by alias); 20 Dec 2009 16:03:22 -0000 Received: (qmail 25657 invoked by uid 22791); 20 Dec 2009 16:03:20 -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; Sun, 20 Dec 2009 16:03:15 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id 5178A400007; Sun, 20 Dec 2009 11:03:12 -0500 (EST) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id nBKG3BFT027097; Sun, 20 Dec 2009 11:03:11 -0500 Date: Sun, 20 Dec 2009 16:03:00 -0000 From: Jack Howarth To: Andrew Haley Cc: Bryce McKinlay , java@gcc.gnu.org, mrs@apple.com, developer@sandoe-acoustics.co.uk Subject: Re: _Unwind_FindEnclosingFunction vs darwin Message-ID: <20091220160311.GA27050@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> <20091219134725.GA29636@bromo.med.uc.edu> <4B2D0CB2.6080705@redhat.com> <20091219184907.GA31305@bromo.med.uc.edu> <7230133d0912191154s18d9c245m9149b5b7f6b0680f@mail.gmail.com> <20091220020259.GA936@bromo.med.uc.edu> <4B2E25AC.6030500@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2E25AC.6030500@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/msg00057.txt.bz2 On Sun, Dec 20, 2009 at 01:25:00PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > > This approach seems cleaner to me... > > > The question to be answered here is, given the bug, what is the simplest and > least intrusive way to fix it. > > There is no need at all to touch gcc/unwind-dw2-fde-darwin.c. > > Please make the Darwin _Unwind_FindEnclosingFunction static inline, > and put it in libjava/include/posix.h. Then it does not export any > new functions, and the symbols are not visible to anything else: the > change is confined to the place it's needed, > > > +#define _Unwind_FindEnclosingFunction(PC) _darwin10_Unwind_FindEnclosingFunction(PC) > > Bryce explained why this is a bad ides, stylistically speaking. > > > with a newly created file gcc/libgcc-darwin10.ver containing _darwin10_Unwind_FindEnclosingFunction. > > > This has the advantages of... > > > > 1) Not duplicating as much code. > > I don't think it makes any difference to the amount of duplicated code. > > > 2) Being easier to maintain when the duplicated code needs to be synchronized with > > new changes to the original routines. > > 3) Allowing for other sections of gcc to utilize the restored calls as well > > as providing an mechanism to easily restore additional calls from FSF libgcc > > that have been silently nooped by Darwin10. > > This is all far too heavyweight; rather than simply solving the problem, it's > speculating about some other problems that may not exist. > > Andrew. Andrew, Can you try the static inline of _Unwind_FindEnclosingFunction on linux and let me know exactly how much code you have to drag into posix.h to allow that function to compile there? I have not had any luck in finding a reasonable amount of ported code that will compile on darwin. Jack