update comments about .objc_ symbols being generated

llvm-svn: 72708

llvm/tools/lto/LTOModule.cpp

@@ -270,8 +270,26 @@ void LTOModule::addDefinedDataSymbol(GlobalValue* v, Mangler& mangler)
     // add to list of defined symbols
     addDefinedSymbol(v, mangler, false); 
 
-    // special case i386/ppc ObjC data structures in magic sections
-    if ( v->hasSection() ) {
+    // Special case i386/ppc ObjC data structures in magic sections:
+    // The issue is that the old ObjC object format did some strange 
+    // contortions to avoid real linker symbols.  For instance, the 
+    // ObjC class data structure is allocated statically in the executable 
+    // that defines that class.  That data structures contains a pointer to
+    // its superclass.  But instead of just initializing that part of the 
+    // struct to the address of its superclass, and letting the static and 
+    // dynamic linkers do the rest, the runtime works by having that field
+    // instead point to a C-string that is the name of the superclass. 
+    // At runtime the objc initialization updates that pointer and sets 
+    // it to point to the actual super class.  As far as the linker
+    // knows it is just a pointer to a string.  But then someone wanted the 
+    // linker to issue errors at build time if the superclass was not found.  
+    // So they figured out a way in mach-o object format to use an absolute 
+    // symbols (.objc_class_name_Foo = 0) and a floating reference 
+    // (.reference .objc_class_name_Bar) to cause the linker into erroring when
+    // a class was missing.   
+    // The following synthesizes the implicit .objc_* symbols for the linker
+    // from the ObjC data structures generated by the front end.
+    if ( v->hasSection() /* && isTargetDarwin */ ) {
         // special case if this data blob is an ObjC class definition
         if ( v->getSection().compare(0, 15, "__OBJC,__class,") == 0 ) {
             if (GlobalVariable* gv = dyn_cast<GlobalVariable>(v)) {