[LLVMdev] OT: intel darwin losing primary target status

[Chris Lattner]

On Sep 18, 2009, at 12:33 PM, Jack Howarth wrote:

> Nick,
>   So is this basically a depreciation of libgcc for darwin10 and
> later?

Hi Jack,

I'm not sure what you mean by depreciation here.  Some perspective:

Darwin (like windows) has it's own system exception handling  
mechanisms and GCC shouldn't try to replace it.  Darwin has always  
been extremely conservative about ABI/API changes: we don't want to  
break our customer apps.  Any changes to libgcc that would break "old"  
unwinder functionality would be unacceptable on our platform,  
regardless of whether the unwinder is part of libsystem or not.

libgcc is still useful for adding other functionality (like emultls as  
you mentioned) as well as other arithmetic support libraries.  I do  
NOT think that "libgcc shouldn't be used on darwin", I just don't  
think the EH pieces should be.

> I was wondering about that very issue awhile ago (as in
> what exactly what relationship clang would have to libgcc). If
> so, perhaps the correct answer is to see if FSF gcc would accept
> changing the default build for darwin10 and later to not use
> the FSF libgcc and instead move any additional symbols into a
> libgcc-ext.

 From my limited understanding, that solution seems like it would work!

-Chris