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

2018-09-27 Thread 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



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2018-09-27 Thread David Chisnall via Phabricator via cfe-commits 
theraven added a comment.

In https://reviews.llvm.org/D47233#1129810, @DHowett-MSFT wrote:

> We ran into some critical issues with this approach on x64. The pointers in 
> the exception record are supposed to be image-relative instead of absolute, 
> so I tried to make them absolute to libobjc2's load address, but I never 
> quite solved it.
>
> A slightly better-documented and cleaner version of the code you linked is 
> here 
> .


(For the reference of other people, since Dustin and I discussed this offline a 
while back)

This is fixed upstream.  We use a stack address as our base address and 
construct stack-variable-relative offsets.  This is safe to do because the only 
requirement for Win64 EH is that the pointers be relative to some arbitrary 
base and in the SEH model the throwing stack frame remains live until the last 
catch.


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

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

2018-07-17 Thread John McCall via Phabricator via cfe-commits 
rjmccall 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())

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.


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

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

2018-07-16 Thread 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())

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.


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

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

2018-07-10 Thread 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:
> > 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?


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

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

2018-06-22 Thread John McCall via Phabricator via cfe-commits 
rjmccall 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())

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.


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

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

2018-06-22 Thread 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:
> 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.


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

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

2018-06-18 Thread John McCall via Phabricator via cfe-commits 
rjmccall 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())

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.


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

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

2018-06-18 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai added a comment.

Ping.


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

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

2018-06-12 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai added a comment.

In https://reviews.llvm.org/D47233#1129810, @DHowett-MSFT wrote:

> In https://reviews.llvm.org/D47233#1129207, @rjmccall wrote:
>
> > In https://reviews.llvm.org/D47233#1129110, @smeenai wrote:
> >
> > > WinObjC does this wrapping, for example.
> >
> >
> > I see.  The idea of creating the type descriptors and mangled names ad-hoc 
> > for the catchable-types array is clever, and it's nice that the ABI is 
> > defined in a way that makes that work.  (Expensive, but hey, it's the 
> > exceptions path.)
>
>
> We ran into some critical issues with this approach on x64. The pointers in 
> the exception record are supposed to be image-relative instead of absolute, 
> so I tried to make them absolute to libobjc2's load address, but I never 
> quite solved it.
>
> A slightly better-documented and cleaner version of the code you linked is 
> here 
> .


We solved the x64 issue by just calling RaiseException directly and supplying a 
fake ImageBase. It's a bit kludgy, but it works well. (_CxxThrowException's 
source is included with MSVC, so we just looked at how that was calling 
RaiseException and altered it accordingly.)


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

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

2018-06-12 Thread Dustin L. Howett via Phabricator via cfe-commits 
DHowett-MSFT added a comment.

In https://reviews.llvm.org/D47233#1129207, @rjmccall wrote:

> In https://reviews.llvm.org/D47233#1129110, @smeenai wrote:
>
> > WinObjC does this wrapping, for example.
>
>
> I see.  The idea of creating the type descriptors and mangled names ad-hoc 
> for the catchable-types array is clever, and it's nice that the ABI is 
> defined in a way that makes that work.  (Expensive, but hey, it's the 
> exceptions path.)


We ran into some critical issues with this approach on x64. The pointers in the 
exception record are supposed to be image-relative instead of absolute, so I 
tried to make them absolute to libobjc2's load address, but I never quite 
solved it.

A slightly better-documented and cleaner version of the code you linked is here 
.


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

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

2018-06-11 Thread John McCall via Phabricator via cfe-commits 
rjmccall added a comment.

In https://reviews.llvm.org/D47233#1129110, @smeenai wrote:

> Wrapping an Objective-C exception inside a C++ exception means dynamically 
> constructing a C++ exception object and traversing the class hierarchy of the 
> thrown Obj-C object to populate the catchable types array of the C++ 
> exception. Microsoft's C++ runtime will perform the appropriate catch type 
> comparisons, and this patch makes the compiler emit the right typeinfos into 
> the exception handling tables for all of that to work. 
> https://github.com/Microsoft/libobjc2/blob/f2e4c5ac4b3ac17f413a38bbc7ee1242f9efd0f7/msvc/eh_winobjc.cc#L116
>  is how WinObjC does this wrapping, for example.


I see.  The idea of creating the type descriptors and mangled names ad-hoc for 
the catchable-types array is clever, and it's nice that the ABI is defined in a 
way that makes that work.  (Expensive, but hey, it's the exceptions path.)

Alright, now that I understand why this only matters for the catch side, I'll 
take a look at the patch.


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

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

2018-06-11 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai added a comment.

Wrapping an Objective-C exception inside a C++ exception means dynamically 
constructing a C++ exception object and traversing the class hierarchy of the 
thrown Obj-C object to populate the catchable types array of the C++ exception. 
Microsoft's C++ runtime will perform the appropriate catch type comparisons, 
and this patch makes the compiler emit the right typeinfos into the exception 
handling tables for all of that to work. 
https://github.com/Microsoft/libobjc2/blob/f2e4c5ac4b3ac17f413a38bbc7ee1242f9efd0f7/msvc/eh_winobjc.cc#L116
 is how WinObjC does this wrapping, for example.

Essentially, with this patch, `@catch (I *)` in Obj-C ends up generating the 
same exception handling table as `catch (struct I *)` in C++ would. If you're 
throwing an `I *` (or any derived class), the runtime will generate an 
exception object which is catchable by this handler (the catchable types array 
for that exception object will contain the appropriate typeinfo). Successive 
catch clauses don't need any special handling; they work the same way as they 
would in C++. The runtime is generating that exception object based on a 
dynamic traversal of the class hierarchy, so I think Obj-C's dynamic semantics 
should be respected.


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

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

2018-06-11 Thread John McCall via Phabricator via cfe-commits 
rjmccall added a comment.

The non-fragile Objective-C path — i.e. interoperation with C++ exceptions 
instead of using `setjmp`/`longjmp` in an utterly-incompatible style — is 
absolutely the right direction going forward.

How does "wrapping an Objective-C exception inside a C++ exception" work?  Do 
you mean that you'll throw and catch a well-known C++ exception type and then 
separately test for subclassing in the catch clause?  How do you intend to 
handle successive catch clauses in that case?  Note that you cannot just wrap 
the Objective-C exception inside a separate C++ exception corresponding to the 
static type of the exception: unlike C++ pointers (even polymorphic ones), 
exception matching for ObjC pointers is based on the dynamic type of the 
exception.


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

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

2018-06-07 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai added a comment.

Ping @rjmccall


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

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

2018-06-07 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai updated this revision to Diff 150399.
smeenai added a comment.

Address objc_exception attribute case


Repository:
  rC Clang

https://reviews.llvm.org/D47233

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGObjCMac.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenObjC/dllstorage.m
  test/CodeGenObjC/exceptions-msvc.m

Index: test/CodeGenObjC/exceptions-msvc.m
===
--- /dev/null
+++ test/CodeGenObjC/exceptions-msvc.m
@@ -0,0 +1,81 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+
+#if __has_feature(objc_arc)
+#define WEAK __weak
+#else
+#define WEAK
+#endif
+
+// CHECK-DAG: $OBJC_EHTYPE_id = comdat any
+// X86-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [18 x i8] c".PAUobjc_object@@\00" }, comdat
+// X64-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [19 x i8] c".PEAUobjc_object@@\00" }, comdat
+
+@class I;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_I" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUI@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUI@@\00" }, comdat
+
+@class J;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_J" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUJ@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUJ@@\00" }, comdat
+
+// The EHType shouldn't be exported
+__declspec(dllexport)
+__attribute__((objc_root_class))
+@interface K
+@end
+
+@implementation K
+@end
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_K" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUK@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUK@@\00" }, comdat
+
+__attribute__((objc_root_class))
+__attribute__((objc_runtime_name("NotL")))
+@interface L
+@end
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_NotL" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUL@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUL@@\00" }, comdat
+
+@class M;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_M" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUM@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUM@@\00" }, comdat
+
+// The EHType shouldn't be generated for this definition, since it's not referenced.
+__attribute__((objc_root_class))
+__attribute__((objc_exception))
+@interface N
+@end
+
+@implementation N
+@end
+
+// CHECK-NOT: @"OBJC_EHTYPE_$_N"
+
+@protocol P;
+
+void f(void);
+
+void g() {
+  @try {
+f();
+  } @catch (I *) {
+  } @catch (J *) {
+  } @catch (K *) {
+  } @catch (L *) {
+  } @catch (M *WEAK) {
+  } @catch (id) {
+  }
+}
Index: test/CodeGenObjC/dllstorage.m
===
--- test/CodeGenObjC/dllstorage.m
+++ test/CodeGenObjC/dllstorage.m
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -fdeclspec -fobjc-runtime=ios -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR %s
-// RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=macosx -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR %s
+// RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=macosx -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR -check-prefix CHECK-ITANIUM %s
 // RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=objfw -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-FW %s
 
 // CHECK-IR-DAG: @_objc_empty_cache = external dllimport global %struct._objc_cache

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

2018-05-30 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai added a comment.

In https://reviews.llvm.org/D47233#1115630, @DHowett-MSFT wrote:

> This largely matches what we've done in the WinObjC clang patchset here 
> ,
>  with the critical exception that we've chosen to mangle the EH names as 
> though they were for structs named after their classes.


Thanks for the pointer!

To clarify, when you're talking about mangling the EH names, do you mean the 
names of the typeinfo structures themselves (OBJC_EHTYPE_* in my 
implementation), or the typeinfo name strings inside those structures? The 
latter should be equivalent to structs for us too, i.e. `@catch (I *)` and 
`catch (struct I *)` would produce the same name in the generated type info.


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

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

2018-05-29 Thread Dustin L. Howett via Phabricator via cfe-commits 
DHowett-MSFT accepted this revision.
DHowett-MSFT added a comment.
This revision is now accepted and ready to land.

This largely matches what we've done in the WinObjC clang patchset here 
,
 with the critical exception that we've chosen to mangle the EH names as though 
they were for structs named after their classes.

Is there some safe generalization that will apply well to all Objective-C 
runtimes, and that we could put in a common place?

Overall, the change seems reasonable to me, but my signoff cannot constitute 
strong-enough acceptance.


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

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

2018-05-25 Thread Reid Kleckner via Phabricator via cfe-commits 
rnk added a comment.

I think the approach makes sense.




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 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?


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

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

2018-05-22 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai updated this revision to Diff 148133.
smeenai added a comment.

Colocate CHECK lines with declarations


Repository:
  rC Clang

https://reviews.llvm.org/D47233

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGObjCMac.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenObjC/dllstorage.m
  test/CodeGenObjC/exceptions-msvc.m

Index: test/CodeGenObjC/exceptions-msvc.m
===
--- /dev/null
+++ test/CodeGenObjC/exceptions-msvc.m
@@ -0,0 +1,69 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+
+#if __has_feature(objc_arc)
+#define WEAK __weak
+#else
+#define WEAK
+#endif
+
+// CHECK-DAG: $OBJC_EHTYPE_id = comdat any
+// X86-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [18 x i8] c".PAUobjc_object@@\00" }, comdat
+// X64-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [19 x i8] c".PEAUobjc_object@@\00" }, comdat
+
+@class I;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_I" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUI@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUI@@\00" }, comdat
+
+@class J;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_J" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUJ@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUJ@@\00" }, comdat
+
+// The EHType shouldn't be exported
+__declspec(dllexport)
+__attribute__((objc_root_class))
+@interface K
+@end
+
+@implementation K
+@end
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_K" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUK@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUK@@\00" }, comdat
+
+__attribute__((objc_runtime_name("NotL")))
+@interface L
+@end
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_NotL" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUL@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUL@@\00" }, comdat
+
+@class M;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_M" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUM@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUM@@\00" }, comdat
+
+@protocol P;
+
+void f(void);
+
+void g() {
+  @try {
+f();
+  } @catch (I *) {
+  } @catch (J *) {
+  } @catch (K *) {
+  } @catch (L *) {
+  } @catch (M *WEAK) {
+  } @catch (id) {
+  }
+}
Index: test/CodeGenObjC/dllstorage.m
===
--- test/CodeGenObjC/dllstorage.m
+++ test/CodeGenObjC/dllstorage.m
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -fdeclspec -fobjc-runtime=ios -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR %s
-// RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=macosx -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR %s
+// RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=macosx -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR -check-prefix CHECK-ITANIUM %s
 // RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=objfw -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-FW %s
 
 // CHECK-IR-DAG: @_objc_empty_cache = external dllimport global %struct._objc_cache
@@ -100,20 +100,20 @@
 @implementation N : I
 @end
 
-// CHECK-IR-DAG: @"OBJC_EHTYPE_$_N" = dso_local dllexport global %struct._objc_typeinfo
+// CHECK-ITANIUM-DAG: @"OBJC_EHTYPE_$_N" = dso_local dllexport global %struct._objc_typeinfo
 
 __declspec(dllimport)

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

2018-05-22 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai created this revision.
smeenai added reviewers: DHowett-MSFT, compnerd, majnemer, rjmccall, rnk.

We're implementing funclet-compatible code generation for Obj-C
exceptions when using the MSVC ABI. The idea is that the Obj-C runtime
will wrap Obj-C exceptions inside C++ exceptions, which allows for
interoperability with C++ exceptions (for Obj-C++) and zero-cost
exceptions. This is the approach taken by e.g. WinObjC, and I believe it
to be the best approach for Obj-C exceptions in the MSVC ABI.

The first step is emitting proper RTTI for Obj-C exception types. Since
we're wrapping Obj-C exceptions in C++ exceptions, the RTTI should be
identical, barring the name of the RTTI variable (OBJC_EHTYPE_$_*).
Since the MSVC ABI does not easily allow for cross-DLL data references
from within other data, we instead emit the RTTI locally wherever
needed, which is also how C++ RTTI works on that ABI.

Follow-up diffs will add code generation support for @try itself, but
I'm splitting it up to get early feedback and make review more
manageable.

Worked on with Saleem Abdulrasool .


Repository:
  rC Clang

https://reviews.llvm.org/D47233

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGObjCMac.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenObjC/dllstorage.m
  test/CodeGenObjC/exceptions-msvc.m

Index: test/CodeGenObjC/exceptions-msvc.m
===
--- /dev/null
+++ test/CodeGenObjC/exceptions-msvc.m
@@ -0,0 +1,68 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+
+// CHECK-DAG: $OBJC_EHTYPE_id = comdat any
+// X86-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [18 x i8] c".PAUobjc_object@@\00" }, comdat
+// X64-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [19 x i8] c".PEAUobjc_object@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_I" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUI@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUI@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_J" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUJ@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUJ@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_K" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUK@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUK@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_NotL" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUL@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUL@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_M" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUM@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUM@@\00" }, comdat
+
+#if __has_feature(objc_arc)
+#define WEAK __weak
+#else
+#define WEAK
+#endif
+
+@class I;
+@class J;
+
+// The EHType shouldn't be exported
+__declspec(dllexport)
+__attribute__((objc_root_class))
+@interface K
+@end
+
+@implementation K
+@end
+
+__attribute__((objc_runtime_name("NotL")))
+@interface L
+@end
+
+@class M;
+
+@protocol P;
+
+void f(void);
+
+void g() {
+  @try {
+f();
+  } @catch (I *) {
+  } @catch (J *) {
+  } @catch (K *) {
+  } @catch (L *) {
+  } @catch (M *WEAK) {
+  } @catch (id) {
+  }
+}
Index: test/CodeGenObjC/dllstorage.m
===
--- test/CodeGenObjC/dllstorage.m
+++ test/CodeGenObjC/dllstorage.m
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -fdeclspec