_Unwind_FindEnclosingFunction vs darwin

_Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

Andrew,
   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
...assuming that the use of _Unwind_FindEnclosingFunction is to tell if the code
address is static of dynamic(JIT) code.
          Jack

Re: _Unwind_FindEnclosingFunction vs darwin

[Andrew Haley]

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.

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

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 am waiting to here back from the Apple unwinder maintainer on that.
Certainly _Unwind_Find_FDE exists for 10.4/10.5, however...

http://www.opensource.apple.com/source/libgcc/libgcc-13/stub.c

shows that it was moved out of libgcc for 10.6. I am unclear if it was
moved into libSystem as a function or as not_implemented macro.
               Jack

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

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?
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)

The most logical place would be in gcc/config/darwin10.h but I am uncertain if
this would be parsed for when libjava compiles libjava/gnu/classpath/natVMStackWalker.cc
so that the call to _Unwind_FindEnclosingFunction() is redirected to
darwin10_Unwind_FindEnclosingFunction(). Any advice would be welcome.
             Jack

Re: _Unwind_FindEnclosingFunction vs darwin

[Andrew Haley]

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.

Re: _Unwind_FindEnclosingFunction vs darwin

[Bryce McKinlay]

On Sat, Dec 19, 2009 at 10:50 AM, Andrew Haley <aph@redhat.com> wrote:

> 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.

Its better style not to make #defines that override function names.

I'd suggest adding a (inline, since you wish to avoid exporting a
function) _Jv_Unwind_FindEnclosingFunction() to posix.h and update all
callers to use that.

This function would either call through to libgcc's implementation, or
contain its own implementation based on _Unwind_Find_FDE depending on
a HAVE_UNWIND_FINDENCLOSINGFUNCTION autoconf define - this would be
undefined on Darwin by checking the ${host} in configure.ac.

On the other hand, if we can rely on _Unwind_Find_FDE being there, I
wonder if there's any reason not to simply move FindEnclosingFunction
into libgcj for all platforms?

Bryce

Re: _Unwind_FindEnclosingFunction vs darwin

[Andrew Haley]

Bryce McKinlay wrote:
> On Sat, Dec 19, 2009 at 10:50 AM, Andrew Haley <aph@redhat.com> wrote:
> 
>> 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.
> 
> Its better style not to make #defines that override function names.

Saints preserve us from poor style.  :-)

> I'd suggest adding a (inline, since you wish to avoid exporting a
> function) _Jv_Unwind_FindEnclosingFunction() to posix.h and update all
> callers to use that.
> 
> This function would either call through to libgcc's implementation, or
> contain its own implementation based on _Unwind_Find_FDE depending on
> a HAVE_UNWIND_FINDENCLOSINGFUNCTION autoconf define - this would be
> undefined on Darwin by checking the ${host} in configure.ac.
> 
> On the other hand, if we can rely on _Unwind_Find_FDE being there, I
> wonder if there's any reason not to simply move FindEnclosingFunction
> into libgcj for all platforms?

We could do, but since that function has been exported for a long time
we'd potentially break other things, which is a pointless risk.

I don't think there's any reason not to use a static inline function
_Jv_Unwind_FindEnclosingFunction() everywhere, except that we're rather
late in the gcc testing cycle, and I know from previous experience that
these seemingly innocent changes can have unforseen side-effects.  This
seems to me to be too large a risk in Stage 3, since its just a tidyup.

How about the safest route, which is a change that affects only darwin now,
any the tidyup immediately we branch?

Andrew.

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

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

Re: _Unwind_FindEnclosingFunction vs darwin

[Andrew Haley]

Jack Howarth wrote:
> 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.

Define it static inline in libjava/include/posix.h..

Andrew.

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

On Sat, Dec 19, 2009 at 05:26:10PM +0000, Andrew Haley wrote:
> >>
> >> 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.
> 
> Define it static inline in libjava/include/posix.h..
> 
> Andrew.

Andrew,
   Okay, so if I add...

static inline 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;
}

#ifdef USING_DARWIN_CRT
#undef _Unwind_FindEnclosingFunction
#define _Unwind_FindEnclosingFunction(PC) _darwin10_Unwind_FindEnclosingFunction(PC)
#endif

to libjava/include/posix.h, what is the correct way to access the missing declarations
for dwarf_eh_bases, dwarf_fde, fde and _Unwind_Find_FDE? Are we supposed to directly
include the *dw2* headers from the gcc subdirectory or duplicate their contents in this
header?
              Jack

Re: _Unwind_FindEnclosingFunction vs darwin

[Bryce McKinlay]

On Sat, Dec 19, 2009 at 6:49 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:

> to libjava/include/posix.h, what is the correct way to access the missing declarations
> for dwarf_eh_bases, dwarf_fde, fde and _Unwind_Find_FDE? Are we supposed to directly
> include the *dw2* headers from the gcc subdirectory or duplicate their contents in this
> header?

I think you only really need to copy the dwarf_eh_bases struct and the
definition for _Unwind_Find_FDE itself. The others can be treated as
opaque.

Please also call it _Jv_Unwind_Find_FDE and use configure.ac to enable
it for Darwin (only) as I described before - its bad to override
functions with #defines...

Bryce

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

On Sat, Dec 19, 2009 at 07:54:15PM +0000, Bryce McKinlay wrote:
> On Sat, Dec 19, 2009 at 6:49 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> 
> > to libjava/include/posix.h, what is the correct way to access the missing declarations
> > for dwarf_eh_bases, dwarf_fde, fde and _Unwind_Find_FDE? Are we supposed to directly
> > include the *dw2* headers from the gcc subdirectory or duplicate their contents in this
> > header?
> 
> I think you only really need to copy the dwarf_eh_bases struct and the
> definition for _Unwind_Find_FDE itself. The others can be treated as
> opaque.
> 
> Please also call it _Jv_Unwind_Find_FDE and use configure.ac to enable
> it for Darwin (only) as I described before - its bad to override
> functions with #defines...
> 
> Bryce

   I confused about the details of functions called within a static inline function.
Do we have to create additional static inlines for each of those called functions
in the same header? If so, we are going to have to add a lot of code from
unwind-dw2-fde-darwin.c since _Unwind_Find_FDE() calls _Unwind_Find_registered_FDE().
Perhaps it would be easier if we added a duplicated _Unwind_FindEnclosingFunction()
to unwind-dw2-fde-darwin.c as _darwin10_Unwind_FindEnclosingFunction() and emitted
that symbol via the versioned libgcc_ext stubs. I know that works in theory and would
be a much smaller patch.
               Jack

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

Bryce,
  This approach seems cleaner to me...

Index: libgcc/config/t-slibgcc-darwin
===================================================================
--- libgcc/config/t-slibgcc-darwin	(revision 155366)
+++ libgcc/config/t-slibgcc-darwin	(working copy)
@@ -24,7 +24,7 @@
 
 SHLIB_MKMAP = $(gcc_srcdir)/mkmap-flat.awk
 SHLIB_MKMAP_OPTS = -v leading_underscore=1
-SHLIB_MAPFILES += $(gcc_srcdir)/libgcc-std.ver
+SHLIB_MAPFILES += $(gcc_srcdir)/libgcc-std.ver $(gcc_srcdir)/libgcc-darwin10.ver
 
 # we're only going to build the stubs if the target slib is /usr/lib
 # there is no other case in which they're useful in a live system.
Index: gcc/unwind-dw2-fde-darwin.c
===================================================================
--- gcc/unwind-dw2-fde-darwin.c	(revision 155366)
+++ gcc/unwind-dw2-fde-darwin.c	(working copy)
@@ -273,3 +273,15 @@
 					  the_obj_info);
   return ret;
 }
+
+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;
+}
+
Index: libjava/include/posix.h
===================================================================
--- libjava/include/posix.h	(revision 155366)
+++ libjava/include/posix.h	(working copy)
@@ -56,6 +56,11 @@
 #define _Jv_platform_solib_suffix ".so"
 #endif
 
+#if defined(__APPLE__) && defined(__MACH__)
+#undef _Unwind_FindEnclosingFunction
+#define _Unwind_FindEnclosingFunction(PC) _darwin10_Unwind_FindEnclosingFunction(PC)
+#endif
+
 // Some POSIX systems don't have O_SYNC and O_DYSNC so we define them here.
 // Needed in java/io/natFileDescriptorPosix.cc.
 #if !defined (O_SYNC) && defined (O_FSYNC)

with a newly created file gcc/libgcc-darwin10.ver containing _darwin10_Unwind_FindEnclosingFunction.
This has the advantages of...

1) Not duplicating as much 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.
                  Jack

Re: _Unwind_FindEnclosingFunction vs darwin

[Bryce McKinlay]

On Sun, Dec 20, 2009 at 2:02 AM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> Bryce,
>  This approach seems cleaner to me...
>
> Index: libgcc/config/t-slibgcc-darwin
> ===================================================================
> --- libgcc/config/t-slibgcc-darwin      (revision 155366)
> +++ libgcc/config/t-slibgcc-darwin      (working copy)
> @@ -24,7 +24,7 @@
>
>  SHLIB_MKMAP = $(gcc_srcdir)/mkmap-flat.awk
>  SHLIB_MKMAP_OPTS = -v leading_underscore=1
> -SHLIB_MAPFILES += $(gcc_srcdir)/libgcc-std.ver
> +SHLIB_MAPFILES += $(gcc_srcdir)/libgcc-std.ver $(gcc_srcdir)/libgcc-darwin10.ver
>
>  # we're only going to build the stubs if the target slib is /usr/lib
>  # there is no other case in which they're useful in a live system.
> Index: gcc/unwind-dw2-fde-darwin.c
> ===================================================================
> --- gcc/unwind-dw2-fde-darwin.c (revision 155366)
> +++ gcc/unwind-dw2-fde-darwin.c (working copy)
> @@ -273,3 +273,15 @@
>                                          the_obj_info);
>   return ret;
>  }
> +
> +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;
> +}
> +
> Index: libjava/include/posix.h
> ===================================================================
> --- libjava/include/posix.h     (revision 155366)
> +++ libjava/include/posix.h     (working copy)
> @@ -56,6 +56,11 @@
>  #define _Jv_platform_solib_suffix ".so"
>  #endif
>
> +#if defined(__APPLE__) && defined(__MACH__)
> +#undef _Unwind_FindEnclosingFunction
> +#define _Unwind_FindEnclosingFunction(PC) _darwin10_Unwind_FindEnclosingFunction(PC)
> +#endif
> +
>  // Some POSIX systems don't have O_SYNC and O_DYSNC so we define them here.
>  // Needed in java/io/natFileDescriptorPosix.cc.
>  #if !defined (O_SYNC) && defined (O_FSYNC)
>
> with a newly created file gcc/libgcc-darwin10.ver containing _darwin10_Unwind_FindEnclosingFunction.
> This has the advantages of...
>
> 1) Not duplicating as much 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.

I thought the plan was to put _Unwind_FindEnclosingFunction into
libgcj, and call _Unwind_Find_FDE instead. But, if that doesn't work
or the libgcc/darwin folks think this approach is a better idea, then
it is fine.

Either way, put the posix.h code inside a static inline _Jv_...
function rather than overriding the function name directly.

Bryce

Re: _Unwind_FindEnclosingFunction vs darwin

[Andrew Haley]

Bryce McKinlay wrote:
> 
> I thought the plan was to put _Unwind_FindEnclosingFunction into
> libgcj, and call _Unwind_Find_FDE instead.

Right.  This reduces the external dependencies, and is a much
cleaner solution.

> Either way, put the posix.h code inside a static inline _Jv_...
> function rather than overriding the function name directly.

I agree.

Andrew.

Re: _Unwind_FindEnclosingFunction vs darwin

[Andrew Haley]

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.

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

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

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

On Sun, Dec 20, 2009 at 01:25:00PM +0000, Andrew Haley wrote:
> 
> 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,
    One other comment. It seems equally heavy-handed to drag in significant
sections of the code from unwind-dw2.c and its associated headers. Also the
solution will never be generic since _Unwind_FindEnclosingFunction() is
declared in unwind-compat.c, unwind-dw2.c and unwind-sjlj.c. I would have
a lot more faith in following this approach if it were first demonstrated
to be workable on linux.
                Jack

Re: _Unwind_FindEnclosingFunction vs darwin

[Andrew Haley]

Jack Howarth wrote:
> On Sun, Dec 20, 2009 at 01:25:00PM +0000, Andrew Haley wrote:
>> This is all far too heavyweight; rather than simply solving the problem, it's
>> speculating about some other problems that may not exist.


>     One other comment. It seems equally heavy-handed to drag in significant
> sections of the code from unwind-dw2.c and its associated headers. Also the
> solution will never be generic since _Unwind_FindEnclosingFunction() is
> declared in unwind-compat.c, unwind-dw2.c and unwind-sjlj.c. I would have
> a lot more faith in following this approach if it were first demonstrated
> to be workable on linux.

Ahhh, I see the problem: _Unwind_Find_FDE isn't exported in libgcc's
headers, so even though it is exported we can't get at its data.  Ouch.

I'm looking at http://refspecs.freestandards.org/abi-eh-1.21.html, and it
doesn't define _Unwind_Find_FDE or give us any way to get the data we need.

OK, I'll go away and think some more.  I think your suggestion may, in fact,
be the best.  Sorry.

Andrew.

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

On Sat, Dec 19, 2009 at 10:50:53AM +0000, Andrew Haley wrote:
> 
> 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.
> 

Andrew,
    It appears that USING_DARWIN_CRT is tested for by configure and used by
Makefile.in and Makefile.am when generating the libjava Makefiles, but it isn't
passed along so we will have to export it. That just adding...

USING_DARWIN_CRT = @USING_DARWIN_CRT@ 

to Makefile.am and Makefile.in, right?
             Jack

Re: _Unwind_FindEnclosingFunction vs darwin

[Andrew Haley]

Jack Howarth wrote:
> On Sat, Dec 19, 2009 at 10:50:53AM +0000, Andrew Haley wrote:
>> 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.
>>
> 
> Andrew,
>     It appears that USING_DARWIN_CRT is tested for by configure and used by
> Makefile.in and Makefile.am when generating the libjava Makefiles, but it isn't
> passed along so we will have to export it. That just adding...
> 
> USING_DARWIN_CRT = @USING_DARWIN_CRT@ 
> 
> to Makefile.am and Makefile.in, right?

I think so.

Andrew.

Re: _Unwind_FindEnclosingFunction vs darwin

[Jack Howarth]

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