Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 02/12/2020 19:01, Frederik Seiffert wrote:
> > Am 01.12.2020 um 15:42 schrieb David Chisnall 
> > <gnustep@theravensnest.org <mailto:gnustep@theravensnest.org>>:
> >
> > 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