* _Unwind_FindEnclosingFunction vs darwin @ 2009-12-18 14:46 Jack Howarth 2009-12-18 15:01 ` Andrew Haley 0 siblings, 1 reply; 22+ messages in thread From: Jack Howarth @ 2009-12-18 14:46 UTC (permalink / raw) To: java, aph 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-18 14:46 _Unwind_FindEnclosingFunction vs darwin Jack Howarth @ 2009-12-18 15:01 ` Andrew Haley 2009-12-18 15:54 ` Jack Howarth ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Andrew Haley @ 2009-12-18 15:01 UTC (permalink / raw) To: Jack Howarth; +Cc: java 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-18 15:01 ` Andrew Haley @ 2009-12-18 15:54 ` Jack Howarth 2009-12-18 20:41 ` Jack Howarth 2009-12-19 0:22 ` Jack Howarth 2 siblings, 0 replies; 22+ messages in thread From: Jack Howarth @ 2009-12-18 15:54 UTC (permalink / raw) To: Andrew Haley; +Cc: java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-18 15:01 ` Andrew Haley 2009-12-18 15:54 ` Jack Howarth @ 2009-12-18 20:41 ` Jack Howarth 2009-12-19 10:51 ` Andrew Haley 2009-12-19 0:22 ` Jack Howarth 2 siblings, 1 reply; 22+ messages in thread From: Jack Howarth @ 2009-12-18 20:41 UTC (permalink / raw) To: Andrew Haley; +Cc: java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-18 20:41 ` Jack Howarth @ 2009-12-19 10:51 ` Andrew Haley 2009-12-19 10:58 ` Bryce McKinlay ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Andrew Haley @ 2009-12-19 10:51 UTC (permalink / raw) To: Jack Howarth; +Cc: java 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 10:51 ` Andrew Haley @ 2009-12-19 10:58 ` Bryce McKinlay 2009-12-19 11:07 ` Andrew Haley 2009-12-19 13:47 ` Jack Howarth 2009-12-19 19:57 ` Jack Howarth 2 siblings, 1 reply; 22+ messages in thread From: Bryce McKinlay @ 2009-12-19 10:58 UTC (permalink / raw) To: Andrew Haley; +Cc: Jack Howarth, java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 10:58 ` Bryce McKinlay @ 2009-12-19 11:07 ` Andrew Haley 0 siblings, 0 replies; 22+ messages in thread From: Andrew Haley @ 2009-12-19 11:07 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Jack Howarth, java 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 10:51 ` Andrew Haley 2009-12-19 10:58 ` Bryce McKinlay @ 2009-12-19 13:47 ` Jack Howarth 2009-12-19 17:26 ` Andrew Haley 2009-12-19 19:57 ` Jack Howarth 2 siblings, 1 reply; 22+ messages in thread From: Jack Howarth @ 2009-12-19 13:47 UTC (permalink / raw) To: Andrew Haley; +Cc: java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 13:47 ` Jack Howarth @ 2009-12-19 17:26 ` Andrew Haley 2009-12-19 18:49 ` Jack Howarth 0 siblings, 1 reply; 22+ messages in thread From: Andrew Haley @ 2009-12-19 17:26 UTC (permalink / raw) To: Jack Howarth; +Cc: java 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 17:26 ` Andrew Haley @ 2009-12-19 18:49 ` Jack Howarth 2009-12-19 19:54 ` Bryce McKinlay 0 siblings, 1 reply; 22+ messages in thread From: Jack Howarth @ 2009-12-19 18:49 UTC (permalink / raw) To: Andrew Haley; +Cc: java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 18:49 ` Jack Howarth @ 2009-12-19 19:54 ` Bryce McKinlay 2009-12-20 0:30 ` Jack Howarth 2009-12-20 2:03 ` Jack Howarth 0 siblings, 2 replies; 22+ messages in thread From: Bryce McKinlay @ 2009-12-19 19:54 UTC (permalink / raw) To: Jack Howarth; +Cc: Andrew Haley, java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 19:54 ` Bryce McKinlay @ 2009-12-20 0:30 ` Jack Howarth 2009-12-20 2:03 ` Jack Howarth 1 sibling, 0 replies; 22+ messages in thread From: Jack Howarth @ 2009-12-20 0:30 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Andrew Haley, java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 19:54 ` Bryce McKinlay 2009-12-20 0:30 ` Jack Howarth @ 2009-12-20 2:03 ` Jack Howarth 2009-12-20 12:14 ` Bryce McKinlay 2009-12-20 13:25 ` Andrew Haley 1 sibling, 2 replies; 22+ messages in thread From: Jack Howarth @ 2009-12-20 2:03 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Andrew Haley, java, mrs, developer 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-20 2:03 ` Jack Howarth @ 2009-12-20 12:14 ` Bryce McKinlay 2009-12-20 13:20 ` Andrew Haley 2009-12-20 13:25 ` Andrew Haley 1 sibling, 1 reply; 22+ messages in thread From: Bryce McKinlay @ 2009-12-20 12:14 UTC (permalink / raw) To: Jack Howarth; +Cc: Andrew Haley, java, mrs, developer 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-20 12:14 ` Bryce McKinlay @ 2009-12-20 13:20 ` Andrew Haley 0 siblings, 0 replies; 22+ messages in thread From: Andrew Haley @ 2009-12-20 13:20 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Jack Howarth, java, mrs, developer 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-20 2:03 ` Jack Howarth 2009-12-20 12:14 ` Bryce McKinlay @ 2009-12-20 13:25 ` Andrew Haley 2009-12-20 16:03 ` Jack Howarth 2009-12-20 16:12 ` Jack Howarth 1 sibling, 2 replies; 22+ messages in thread From: Andrew Haley @ 2009-12-20 13:25 UTC (permalink / raw) To: Jack Howarth; +Cc: Bryce McKinlay, java, mrs, developer 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-20 13:25 ` Andrew Haley @ 2009-12-20 16:03 ` Jack Howarth 2009-12-20 16:12 ` Jack Howarth 1 sibling, 0 replies; 22+ messages in thread From: Jack Howarth @ 2009-12-20 16:03 UTC (permalink / raw) To: Andrew Haley; +Cc: Bryce McKinlay, java, mrs, developer 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-20 13:25 ` Andrew Haley 2009-12-20 16:03 ` Jack Howarth @ 2009-12-20 16:12 ` Jack Howarth 2009-12-20 17:47 ` Andrew Haley 1 sibling, 1 reply; 22+ messages in thread From: Jack Howarth @ 2009-12-20 16:12 UTC (permalink / raw) To: Andrew Haley; +Cc: Bryce McKinlay, java, mrs, developer 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-20 16:12 ` Jack Howarth @ 2009-12-20 17:47 ` Andrew Haley 0 siblings, 0 replies; 22+ messages in thread From: Andrew Haley @ 2009-12-20 17:47 UTC (permalink / raw) To: Jack Howarth; +Cc: Bryce McKinlay, java, mrs, developer 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 10:51 ` Andrew Haley 2009-12-19 10:58 ` Bryce McKinlay 2009-12-19 13:47 ` Jack Howarth @ 2009-12-19 19:57 ` Jack Howarth 2009-12-20 13:26 ` Andrew Haley 2 siblings, 1 reply; 22+ messages in thread From: Jack Howarth @ 2009-12-19 19:57 UTC (permalink / raw) To: Andrew Haley; +Cc: java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-19 19:57 ` Jack Howarth @ 2009-12-20 13:26 ` Andrew Haley 0 siblings, 0 replies; 22+ messages in thread From: Andrew Haley @ 2009-12-20 13:26 UTC (permalink / raw) To: Jack Howarth; +Cc: java 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: _Unwind_FindEnclosingFunction vs darwin 2009-12-18 15:01 ` Andrew Haley 2009-12-18 15:54 ` Jack Howarth 2009-12-18 20:41 ` Jack Howarth @ 2009-12-19 0:22 ` Jack Howarth 2 siblings, 0 replies; 22+ messages in thread From: Jack Howarth @ 2009-12-19 0:22 UTC (permalink / raw) To: Andrew Haley; +Cc: java 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2009-12-20 17:47 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-12-18 14:46 _Unwind_FindEnclosingFunction vs darwin Jack Howarth 2009-12-18 15:01 ` Andrew Haley 2009-12-18 15:54 ` Jack Howarth 2009-12-18 20:41 ` Jack Howarth 2009-12-19 10:51 ` Andrew Haley 2009-12-19 10:58 ` Bryce McKinlay 2009-12-19 11:07 ` Andrew Haley 2009-12-19 13:47 ` Jack Howarth 2009-12-19 17:26 ` Andrew Haley 2009-12-19 18:49 ` Jack Howarth 2009-12-19 19:54 ` Bryce McKinlay 2009-12-20 0:30 ` Jack Howarth 2009-12-20 2:03 ` Jack Howarth 2009-12-20 12:14 ` Bryce McKinlay 2009-12-20 13:20 ` Andrew Haley 2009-12-20 13:25 ` Andrew Haley 2009-12-20 16:03 ` Jack Howarth 2009-12-20 16:12 ` Jack Howarth 2009-12-20 17:47 ` Andrew Haley 2009-12-19 19:57 ` Jack Howarth 2009-12-20 13:26 ` Andrew Haley 2009-12-19 0:22 ` Jack Howarth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).