_Unwind_FindEnclosingFunction vs darwin
Bryce McKinlay
bmckinlay@gmail.com
Sun Dec 20 12:14:00 GMT 2009
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
More information about the Java
mailing list