Re: _Unwind_FindEnclosingFunction vs darwin

On Fri, Dec 18, 2009 at 03:01:08PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> 
> >    As I mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c36,
> > the darwin unwinder maintainer looked at the crash of gcj(ecj1) when compiling
> > java code on darwin10. He claims that the origin of the problem is the use of
> > the FSF unwinder extension _Unwind_FindEnclosingFunction which is not implemented
> > in the system unwinder on darwin10. It appears that for darwin10 and later we
> > will have to replace the call to _Unwind_FindEnclosingFunction on darwin with
> > code using dladdr() to discover if the function is known to the dynamic loader
> 
> That won't work.
> 
> > ...assuming that the use of _Unwind_FindEnclosingFunction is to tell if the code
> > address is static of dynamic(JIT) code.
> 
> _Unwind_FindEnclosingFunction is trivial:
> 
> void *
> _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;
> }
> 
> _Unwind_Find_FDE is a standard function.  Does Darwin support that?
> 
> Andrew.

Andrew,
   I did an ugly little proof of concept build for gcc trunk where
I duplicated the declarations for _Unwind_FindEnclosingFunction
as _darwin10__Unwind_FindEnclosingFunction so that this symbol is
exported from the versioned libgcc_ext. Changing the call to
_Unwind_FindEnclosingFunction() to _darwin10__Unwind_FindEnclosingFunction()
in libjava/gnu/classpath/natVMStackWalker.cc eliminated the failures
in the WalkerTest testcase. This change also eliminates the crash in
gcj(ecj1) when compiling java code under darwin10.
   What are our best options for fixing this without adding additional
symbols to libgcc?
                Jack