Re: _Unwind_FindEnclosingFunction vs darwin

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