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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
