Re: Building GNUstep for Windows using Clang

On 02/12/2020 19:01, Frederik Seiffert wrote:
> 
>> Am 01.12.2020 um 15:42 schrieb David Chisnall 
>> <[email protected] <mailto:[email protected]>>:
>>
>> Please can you try the attached patch?
> 
> So the patch resolves the objc_begin_catch/objc_end_catch undefined 
> symbols, but it doesn’t resolve __gnustep_objc_personality_v0 and adds 
> some new linker errors ones:
> 
>> lld-link: error: undefined symbol: __gnustep_objc_personality_v0
>> >>> referenced by 
>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(.xdata)
>> >>> referenced by 
>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(GCC_except_table2)
>> >>> referenced by 
>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(GCC_except_table4)
>> >>> referenced 121 more times

It looks as if the code to check which personality function is outside 
the runtime-specific code.  The attached diff should fix that.

>>
>> lld-link: error: undefined symbol: vtable for 
>> __cxxabiv1::__class_type_info
>> >>> referenced by 
>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for NSObject)
>> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o
>>
>> lld-link: error: undefined symbol: vtable for 
>> __cxxabiv1::__si_class_type_info
>> >>> referenced by 
>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for 
>> NSException)
>> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o
>>
>> lld-link: error: undefined symbol: vtable for 
>> __cxxabiv1::__pointer_type_info
>> >>> referenced by 
>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for 
>> NSException*)
>> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o

This looks as if clang is still trying to use the Itanium C++ ABI.  When 
the Objective-C code is targeting windows, it now asks for RTTI from the 
CXXABI class, but somehow your target triple is asking for the Itanium 
ABI, so we emit Itanium ABI C++ RTTI things and they then fail to link 
because they refer to things that exist only on Itanium ABI C++ runtimes.

I am not sure if there is a good way of fixing this other than to use a 
MSVC target triple.  C++ EH interop almost certainly won't work if MinGW 
is targeting the Itanium ABI for C++ and I really don't want to support 
the horrible 'let's try to layer Itanium-style unwinding on top of SEH, 
what's the worst that can happen?' approach that MinGW uses.

David

index bdf70252b5ad..5957b5fff0d5 100644
--- a/clang/lib/CodeGen/CGException.cpp
+++ b/clang/lib/CodeGen/CGException.cpp
@@ -141,7 +141,9 @@ static const EHPersonality &getObjCPersonality(const 
TargetInfo &Target,
    case ObjCRuntime::iOS:
    case ObjCRuntime::WatchOS:
      return EHPersonality::NeXT_ObjC;
-  case ObjCRuntime::GNUstep:
+  case ObjCRuntime::GNUstep:
+    if (L.SEHExceptions)
+      return EHPersonality::MSVC_CxxFrameHandler3;
      if (L.ObjCRuntime.getVersion() >= VersionTuple(1, 7))
        return EHPersonality::GNUstep_ObjC;
      LLVM_FALLTHROUGH;
@@ -194,6 +196,8 @@ static const EHPersonality 
&getObjCXXPersonality(const TargetInfo &Target,
      return getObjCPersonality(Target, L);

    case ObjCRuntime::GNUstep:
+    if (L.SEHExceptions)
+      return EHPersonality::MSVC_CxxFrameHandler3;
      return EHPersonality::GNU_ObjCXX;

    // The GCC runtime's personality function inherently doesn't support