1 //===--- TargetCXXABI.h - C++ ABI Target Configuration ----------*- C++ -*-===// 2 // 3 // The LLVM Compiler Infrastructure 4 // 5 // This file is distributed under the University of Illinois Open Source 6 // License. See LICENSE.TXT for details. 7 // 8 //===----------------------------------------------------------------------===// 9 /// 10 /// \file 11 /// \brief Defines the TargetCXXABI class, which abstracts details of the 12 /// C++ ABI that we're targeting. 13 /// 14 //===----------------------------------------------------------------------===// 15 16 #ifndef LLVM_CLANG_TARGETCXXABI_H 17 #define LLVM_CLANG_TARGETCXXABI_H 18 19 #include "llvm/ADT/Triple.h" 20 #include "llvm/Support/ErrorHandling.h" 21 22 namespace clang { 23 24 /// \brief The basic abstraction for the target C++ ABI. 25 class TargetCXXABI { 26 public: 27 /// \brief The basic C++ ABI kind. 28 enum Kind { 29 /// The generic Itanium ABI is the standard ABI of most open-source 30 /// and Unix-like platforms. It is the primary ABI targeted by 31 /// many compilers, including Clang and GCC. 32 /// 33 /// It is documented here: 34 /// http://www.codesourcery.com/public/cxx-abi/ 35 GenericItanium, 36 37 /// The generic ARM ABI is a modified version of the Itanium ABI 38 /// proposed by ARM for use on ARM-based platforms. 39 /// 40 /// These changes include: 41 /// - the representation of member function pointers is adjusted 42 /// to not conflict with the 'thumb' bit of ARM function pointers; 43 /// - constructors and destructors return 'this'; 44 /// - guard variables are smaller; 45 /// - inline functions are never key functions; 46 /// - array cookies have a slightly different layout; 47 /// - additional convenience functions are specified; 48 /// - and more! 49 /// 50 /// It is documented here: 51 /// http://infocenter.arm.com 52 /// /help/topic/com.arm.doc.ihi0041c/IHI0041C_cppabi.pdf 53 GenericARM, 54 55 /// The iOS ABI is a partial implementation of the ARM ABI. 56 /// Several of the features of the ARM ABI were not fully implemented 57 /// in the compilers that iOS was launched with. 58 /// 59 /// Essentially, the iOS ABI includes the ARM changes to: 60 /// - member function pointers, 61 /// - guard variables, 62 /// - array cookies, and 63 /// - constructor/destructor signatures. 64 iOS, 65 66 /// The generic AArch64 ABI is also a modified version of the Itanium ABI, 67 /// but it has fewer divergences than the 32-bit ARM ABI. 68 /// 69 /// The relevant changes from the generic ABI in this case are: 70 /// - representation of member function pointers adjusted as in ARM. 71 /// - guard variables are smaller. 72 GenericAArch64, 73 74 /// The Microsoft ABI is the ABI used by Microsoft Visual Studio (and 75 /// compatible compilers). 76 /// 77 /// FIXME: should this be split into Win32 and Win64 variants? 78 /// 79 /// Only scattered and incomplete official documentation exists. 80 Microsoft 81 }; 82 83 private: 84 // Right now, this class is passed around as a cheap value type. 85 // If you add more members, especially non-POD members, please 86 // audit the users to pass it by reference instead. 87 Kind TheKind; 88 89 public: 90 /// A bogus initialization of the platform ABI. TargetCXXABI()91 TargetCXXABI() : TheKind(GenericItanium) {} 92 TargetCXXABI(Kind kind)93 TargetCXXABI(Kind kind) : TheKind(kind) {} 94 set(Kind kind)95 void set(Kind kind) { 96 TheKind = kind; 97 } 98 getKind()99 Kind getKind() const { return TheKind; } 100 101 /// \brief Does this ABI generally fall into the Itanium family of ABIs? isItaniumFamily()102 bool isItaniumFamily() const { 103 switch (getKind()) { 104 case GenericAArch64: 105 case GenericItanium: 106 case GenericARM: 107 case iOS: 108 return true; 109 110 case Microsoft: 111 return false; 112 } 113 llvm_unreachable("bad ABI kind"); 114 } 115 116 /// \brief Is this ABI an MSVC-compatible ABI? isMicrosoft()117 bool isMicrosoft() const { 118 switch (getKind()) { 119 case GenericAArch64: 120 case GenericItanium: 121 case GenericARM: 122 case iOS: 123 return false; 124 125 case Microsoft: 126 return true; 127 } 128 llvm_unreachable("bad ABI kind"); 129 } 130 131 /// \brief Is the default C++ member function calling convention 132 /// the same as the default calling convention? isMemberFunctionCCDefault()133 bool isMemberFunctionCCDefault() const { 134 // Right now, this is always true for Microsoft. 135 return !isMicrosoft(); 136 } 137 138 /// \brief Does this ABI have different entrypoints for complete-object 139 /// and base-subobject constructors? hasConstructorVariants()140 bool hasConstructorVariants() const { 141 return isItaniumFamily(); 142 } 143 144 /// \brief Does this ABI have different entrypoints for complete-object 145 /// and base-subobject destructors? hasDestructorVariants()146 bool hasDestructorVariants() const { 147 return isItaniumFamily(); 148 } 149 150 /// \brief Does this ABI allow virtual bases to be primary base classes? hasPrimaryVBases()151 bool hasPrimaryVBases() const { 152 return isItaniumFamily(); 153 } 154 155 /// \brief Can an out-of-line inline function serve as a key function? 156 /// 157 /// This flag is only useful in ABIs where type data (for example, 158 /// v-tables and type_info objects) are emitted only after processing 159 /// the definition of a special "key" virtual function. (This is safe 160 /// because the ODR requires that every virtual function be defined 161 /// somewhere in a program.) This usually permits such data to be 162 /// emitted in only a single object file, as opposed to redundantly 163 /// in every object file that requires it. 164 /// 165 /// One simple and common definition of "key function" is the first 166 /// virtual function in the class definition which is not defined there. 167 /// This rule works very well when that function has a non-inline 168 /// definition in some non-header file. Unfortunately, when that 169 /// function is defined inline, this rule requires the type data 170 /// to be emitted weakly, as if there were no key function. 171 /// 172 /// The ARM ABI observes that the ODR provides an additional guarantee: 173 /// a virtual function is always ODR-used, so if it is defined inline, 174 /// that definition must appear in every translation unit that defines 175 /// the class. Therefore, there is no reason to allow such functions 176 /// to serve as key functions. 177 /// 178 /// Because this changes the rules for emitting type data, 179 /// it can cause type data to be emitted with both weak and strong 180 /// linkage, which is not allowed on all platforms. Therefore, 181 /// exploiting this observation requires an ABI break and cannot be 182 /// done on a generic Itanium platform. canKeyFunctionBeInline()183 bool canKeyFunctionBeInline() const { 184 switch (getKind()) { 185 case GenericARM: 186 return false; 187 188 case GenericAArch64: 189 case GenericItanium: 190 case iOS: // old iOS compilers did not follow this rule 191 case Microsoft: 192 return true; 193 } 194 llvm_unreachable("bad ABI kind"); 195 } 196 197 /// When is record layout allowed to allocate objects in the tail 198 /// padding of a base class? 199 /// 200 /// This decision cannot be changed without breaking platform ABI 201 /// compatibility, and yet it is tied to language guarantees which 202 /// the committee has so far seen fit to strengthen no less than 203 /// three separate times: 204 /// - originally, there were no restrictions at all; 205 /// - C++98 declared that objects could not be allocated in the 206 /// tail padding of a POD type; 207 /// - C++03 extended the definition of POD to include classes 208 /// containing member pointers; and 209 /// - C++11 greatly broadened the definition of POD to include 210 /// all trivial standard-layout classes. 211 /// Each of these changes technically took several existing 212 /// platforms and made them permanently non-conformant. 213 enum TailPaddingUseRules { 214 /// The tail-padding of a base class is always theoretically 215 /// available, even if it's POD. This is not strictly conforming 216 /// in any language mode. 217 AlwaysUseTailPadding, 218 219 /// Only allocate objects in the tail padding of a base class if 220 /// the base class is not POD according to the rules of C++ TR1. 221 /// This is non strictly conforming in C++11 mode. 222 UseTailPaddingUnlessPOD03, 223 224 /// Only allocate objects in the tail padding of a base class if 225 /// the base class is not POD according to the rules of C++11. 226 UseTailPaddingUnlessPOD11 227 }; getTailPaddingUseRules()228 TailPaddingUseRules getTailPaddingUseRules() const { 229 switch (getKind()) { 230 // To preserve binary compatibility, the generic Itanium ABI has 231 // permanently locked the definition of POD to the rules of C++ TR1, 232 // and that trickles down to all the derived ABIs. 233 case GenericItanium: 234 case GenericAArch64: 235 case GenericARM: 236 case iOS: 237 return UseTailPaddingUnlessPOD03; 238 239 // MSVC always allocates fields in the tail-padding of a base class 240 // subobject, even if they're POD. 241 case Microsoft: 242 return AlwaysUseTailPadding; 243 } 244 llvm_unreachable("bad ABI kind"); 245 } 246 247 /// Try to parse an ABI name, returning false on error. 248 bool tryParse(llvm::StringRef name); 249 250 friend bool operator==(const TargetCXXABI &left, const TargetCXXABI &right) { 251 return left.getKind() == right.getKind(); 252 } 253 254 friend bool operator!=(const TargetCXXABI &left, const TargetCXXABI &right) { 255 return !(left == right); 256 } 257 }; 258 259 } // end namespace clang 260 261 #endif 262