Re: _Unwind_FindEnclosingFunction vs darwin

Bryce McKinlay wrote:
> On Sat, Dec 19, 2009 at 10:50 AM, Andrew Haley <[email protected]> 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.