[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.


================
Comment at: lib/CodeGen/CGObjCMac.cpp:7457-7460
 CGObjCNonFragileABIMac::GetEHType(QualType T) {
   // There's a particular fixed type info for 'id'.
   if (T->isObjCIdType() || T->isObjCQualifiedIdType()) {
+    if (CGM.getTriple().isWindowsMSVCEnvironment())
----------------
rjmccall wrote:
> smeenai wrote:
> > smeenai wrote:
> > > rjmccall wrote:
> > > > smeenai wrote:
> > > > > rjmccall wrote:
> > > > > > rnk wrote:
> > > > > > > @rjmccall how should this be organized in the long run? At this point, the naming seems totally wrong. Is the non-fragile ABI sort of the canonical way forward for Obj-C, i.e. it's what a new platform would want to use to best stay in sync with the future of obj-c?
> > > > > > For Darwin, yes, absolutely.
> > > > > > 
> > > > > > I think this method should probably just completely delegate to the `CGCXXABI` using a new `getAddrOfObjCRTTIDescriptor` method.
> > > > > To be clear, you'd want the entirety of the EHType emission logic to be shifted to CGCXXABI? I think that would make sense, and I can look into it.
> > > > Right.
> > > Sorry, getting back to this now.
> > > 
> > > What did you have in mind for handling the different Obj-C runtimes? Were you envisioning the new getAddrOfObjCRTTIDescriptor method supporting just the non-fragile Mac ABI or all of them?
> > Looked into this more. ItaniumRTTIBuilder already has a BuildObjCObjectTypeInfo, which confused me for a bit until I realized it's only ever used for the fragile ABI, and even then only when using C++ try/catch (instead of Obj-C style @try/@catch), which is a bit strange. Everything else does its own thing.
> > 
> > From what I've been able to make out, these are the current possibilities for generating Obj-C RTTI for the Itanium ABI:
> > * Fragile macOS runtime using Obj-C @try/@catch: doesn't actually seem to generate any RTTI as far as I can tell, and uses `objc_exception_match` instead.
> > * Fragile macOS runtime using C++ try/catch: goes through `ItaniumRTTIBuilder::BuildObjCObjectTypeInfo`, which generates C++ compatible RTTI referencing a C++ class type info.
> > * Non-fragile macOS runtime: generates its own C++ compatible RTTI referencing `objc_ehtype_vtable`.
> > * GNUStep for Objective-C++: generates its own C++ compatible RTTI referencing `_ZTVN7gnustep7libobjc22__objc_class_type_infoE`.
> > * All other GNU runtimes (including GNUStep for Objective-C): just uses the identifier name string of the interface as its "RTTI".
> > 
> > I think it makes sense to only have the new `getAddrOfObjCRTTIDescriptor` method handle the non-fragile macOS runtime for now, and perhaps `ItaniumRTTIBuilder::BuildObjCObjectTypeInfo` should be renamed (or at least have a comment added) to indicate that it's only used for the fragile macOS runtime when catching an Obj-C type with C++ catch.
> Yeah, that makes sense to me for now.
@rjmccall Sorry, I've been severely distracted, but I'm trying to come back and finish this up now. I'm fully aware you've probably lost all context on this by now as well, and I do apologize for the delay.

I did try implementing this approach, where I had `getAddrOfObjCRTTIDescriptor` as part of `CGCXXABI`. I ran into issues with trying to take the existing Itanium implementation of `CGObjCNonFragileABIMac::GetInterfaceEHType` and porting it over to to `CGCXXABI`, however. Specifically, it calls `GetClassName` and `GetClassGlobal`, both of which are non-trivial internal functions, and which I would then have to make accessible to `CGCXXABI` to end up with equivalent RTT generation.

I can put up a diff demonstrating what it would end up looking like if you want to see it, but I'm less convinced now that moving the entire RTTI emission logic out to `CGCXXABI` will end up being cleaner.


Repository:
  rC Clang

https://reviews.llvm.org/D47233