|
|
|||
File indexing completed on 2026-05-10 08:36:51
0001 //===--- TargetCXXABI.h - C++ ABI Target Configuration ----------*- C++ -*-===// 0002 // 0003 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. 0004 // See https://llvm.org/LICENSE.txt for license information. 0005 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception 0006 // 0007 //===----------------------------------------------------------------------===// 0008 /// 0009 /// \file 0010 /// Defines the TargetCXXABI class, which abstracts details of the 0011 /// C++ ABI that we're targeting. 0012 /// 0013 //===----------------------------------------------------------------------===// 0014 0015 #ifndef LLVM_CLANG_BASIC_TARGETCXXABI_H 0016 #define LLVM_CLANG_BASIC_TARGETCXXABI_H 0017 0018 #include <map> 0019 0020 #include "clang/Basic/LLVM.h" 0021 #include "llvm/ADT/StringMap.h" 0022 #include "llvm/Support/ErrorHandling.h" 0023 #include "llvm/TargetParser/Triple.h" 0024 0025 namespace clang { 0026 0027 /// The basic abstraction for the target C++ ABI. 0028 class TargetCXXABI { 0029 public: 0030 /// The basic C++ ABI kind. 0031 enum Kind { 0032 #define CXXABI(Name, Str) Name, 0033 #include "TargetCXXABI.def" 0034 }; 0035 0036 private: 0037 // Right now, this class is passed around as a cheap value type. 0038 // If you add more members, especially non-POD members, please 0039 // audit the users to pass it by reference instead. 0040 Kind TheKind; 0041 0042 static const auto &getABIMap() { 0043 static llvm::StringMap<Kind> ABIMap = { 0044 #define CXXABI(Name, Str) {Str, Name}, 0045 #include "TargetCXXABI.def" 0046 }; 0047 return ABIMap; 0048 } 0049 0050 static const auto &getSpellingMap() { 0051 static std::map<Kind, std::string> SpellingMap = { 0052 #define CXXABI(Name, Str) {Name, Str}, 0053 #include "TargetCXXABI.def" 0054 }; 0055 return SpellingMap; 0056 } 0057 0058 public: 0059 static Kind getKind(StringRef Name) { return getABIMap().lookup(Name); } 0060 static const auto &getSpelling(Kind ABIKind) { 0061 return getSpellingMap().find(ABIKind)->second; 0062 } 0063 static bool isABI(StringRef Name) { return getABIMap().contains(Name); } 0064 0065 // Return true if this target should use the relative vtables C++ ABI by 0066 // default. 0067 static bool usesRelativeVTables(const llvm::Triple &T) { 0068 return T.isOSFuchsia(); 0069 } 0070 0071 /// A bogus initialization of the platform ABI. 0072 TargetCXXABI() : TheKind(GenericItanium) {} 0073 0074 TargetCXXABI(Kind kind) : TheKind(kind) {} 0075 0076 void set(Kind kind) { 0077 TheKind = kind; 0078 } 0079 0080 Kind getKind() const { return TheKind; } 0081 0082 // Check that the kind provided by the fc++-abi flag is supported on this 0083 // target. Users who want to experiment using different ABIs on specific 0084 // platforms can change this freely, but this function should be conservative 0085 // enough such that not all ABIs are allowed on all platforms. For example, we 0086 // probably don't want to allow usage of an ARM ABI on an x86 architecture. 0087 static bool isSupportedCXXABI(const llvm::Triple &T, Kind Kind) { 0088 switch (Kind) { 0089 case GenericARM: 0090 return T.isARM() || T.isAArch64(); 0091 0092 case iOS: 0093 case WatchOS: 0094 case AppleARM64: 0095 return T.isOSDarwin(); 0096 0097 case Fuchsia: 0098 return T.isOSFuchsia(); 0099 0100 case GenericAArch64: 0101 return T.isAArch64(); 0102 0103 case GenericMIPS: 0104 return T.isMIPS(); 0105 0106 case WebAssembly: 0107 return T.isWasm(); 0108 0109 case XL: 0110 return T.isOSAIX(); 0111 0112 case GenericItanium: 0113 return true; 0114 0115 case Microsoft: 0116 return T.isKnownWindowsMSVCEnvironment(); 0117 } 0118 llvm_unreachable("invalid CXXABI kind"); 0119 } 0120 0121 /// Does this ABI generally fall into the Itanium family of ABIs? 0122 bool isItaniumFamily() const { 0123 switch (getKind()) { 0124 #define CXXABI(Name, Str) 0125 #define ITANIUM_CXXABI(Name, Str) case Name: 0126 #include "TargetCXXABI.def" 0127 return true; 0128 0129 default: 0130 return false; 0131 } 0132 llvm_unreachable("bad ABI kind"); 0133 } 0134 0135 /// Is this ABI an MSVC-compatible ABI? 0136 bool isMicrosoft() const { 0137 switch (getKind()) { 0138 #define CXXABI(Name, Str) 0139 #define MICROSOFT_CXXABI(Name, Str) case Name: 0140 #include "TargetCXXABI.def" 0141 return true; 0142 0143 default: 0144 return false; 0145 } 0146 llvm_unreachable("bad ABI kind"); 0147 } 0148 0149 /// Are member functions differently aligned? 0150 /// 0151 /// Many Itanium-style C++ ABIs require member functions to be aligned, so 0152 /// that a pointer to such a function is guaranteed to have a zero in the 0153 /// least significant bit, so that pointers to member functions can use that 0154 /// bit to distinguish between virtual and non-virtual functions. However, 0155 /// some Itanium-style C++ ABIs differentiate between virtual and non-virtual 0156 /// functions via other means, and consequently don't require that member 0157 /// functions be aligned. 0158 bool areMemberFunctionsAligned() const { 0159 switch (getKind()) { 0160 case WebAssembly: 0161 // WebAssembly doesn't require any special alignment for member functions. 0162 return false; 0163 case AppleARM64: 0164 case Fuchsia: 0165 case GenericARM: 0166 case GenericAArch64: 0167 case GenericMIPS: 0168 // TODO: ARM-style pointers to member functions put the discriminator in 0169 // the this adjustment, so they don't require functions to have any 0170 // special alignment and could therefore also return false. 0171 case GenericItanium: 0172 case iOS: 0173 case WatchOS: 0174 case Microsoft: 0175 case XL: 0176 return true; 0177 } 0178 llvm_unreachable("bad ABI kind"); 0179 } 0180 0181 /// Are arguments to a call destroyed left to right in the callee? 0182 /// This is a fundamental language change, since it implies that objects 0183 /// passed by value do *not* live to the end of the full expression. 0184 /// Temporaries passed to a function taking a const reference live to the end 0185 /// of the full expression as usual. Both the caller and the callee must 0186 /// have access to the destructor, while only the caller needs the 0187 /// destructor if this is false. 0188 bool areArgsDestroyedLeftToRightInCallee() const { 0189 return isMicrosoft(); 0190 } 0191 0192 /// Does this ABI have different entrypoints for complete-object 0193 /// and base-subobject constructors? 0194 bool hasConstructorVariants() const { 0195 return isItaniumFamily(); 0196 } 0197 0198 /// Does this ABI allow virtual bases to be primary base classes? 0199 bool hasPrimaryVBases() const { 0200 return isItaniumFamily(); 0201 } 0202 0203 /// Does this ABI use key functions? If so, class data such as the 0204 /// vtable is emitted with strong linkage by the TU containing the key 0205 /// function. 0206 bool hasKeyFunctions() const { 0207 return isItaniumFamily(); 0208 } 0209 0210 /// Can an out-of-line inline function serve as a key function? 0211 /// 0212 /// This flag is only useful in ABIs where type data (for example, 0213 /// vtables and type_info objects) are emitted only after processing 0214 /// the definition of a special "key" virtual function. (This is safe 0215 /// because the ODR requires that every virtual function be defined 0216 /// somewhere in a program.) This usually permits such data to be 0217 /// emitted in only a single object file, as opposed to redundantly 0218 /// in every object file that requires it. 0219 /// 0220 /// One simple and common definition of "key function" is the first 0221 /// virtual function in the class definition which is not defined there. 0222 /// This rule works very well when that function has a non-inline 0223 /// definition in some non-header file. Unfortunately, when that 0224 /// function is defined inline, this rule requires the type data 0225 /// to be emitted weakly, as if there were no key function. 0226 /// 0227 /// The ARM ABI observes that the ODR provides an additional guarantee: 0228 /// a virtual function is always ODR-used, so if it is defined inline, 0229 /// that definition must appear in every translation unit that defines 0230 /// the class. Therefore, there is no reason to allow such functions 0231 /// to serve as key functions. 0232 /// 0233 /// Because this changes the rules for emitting type data, 0234 /// it can cause type data to be emitted with both weak and strong 0235 /// linkage, which is not allowed on all platforms. Therefore, 0236 /// exploiting this observation requires an ABI break and cannot be 0237 /// done on a generic Itanium platform. 0238 bool canKeyFunctionBeInline() const { 0239 switch (getKind()) { 0240 case AppleARM64: 0241 case Fuchsia: 0242 case GenericARM: 0243 case WebAssembly: 0244 case WatchOS: 0245 return false; 0246 0247 case GenericAArch64: 0248 case GenericItanium: 0249 case iOS: // old iOS compilers did not follow this rule 0250 case Microsoft: 0251 case GenericMIPS: 0252 case XL: 0253 return true; 0254 } 0255 llvm_unreachable("bad ABI kind"); 0256 } 0257 0258 /// When is record layout allowed to allocate objects in the tail 0259 /// padding of a base class? 0260 /// 0261 /// This decision cannot be changed without breaking platform ABI 0262 /// compatibility. In ISO C++98, tail padding reuse was only permitted for 0263 /// non-POD base classes, but that restriction was removed retroactively by 0264 /// DR 43, and tail padding reuse is always permitted in all de facto C++ 0265 /// language modes. However, many platforms use a variant of the old C++98 0266 /// rule for compatibility. 0267 enum TailPaddingUseRules { 0268 /// The tail-padding of a base class is always theoretically 0269 /// available, even if it's POD. 0270 AlwaysUseTailPadding, 0271 0272 /// Only allocate objects in the tail padding of a base class if 0273 /// the base class is not POD according to the rules of C++ TR1. 0274 UseTailPaddingUnlessPOD03, 0275 0276 /// Only allocate objects in the tail padding of a base class if 0277 /// the base class is not POD according to the rules of C++11. 0278 UseTailPaddingUnlessPOD11 0279 }; 0280 TailPaddingUseRules getTailPaddingUseRules() const { 0281 switch (getKind()) { 0282 // To preserve binary compatibility, the generic Itanium ABI has 0283 // permanently locked the definition of POD to the rules of C++ TR1, 0284 // and that trickles down to derived ABIs. 0285 case GenericItanium: 0286 case GenericAArch64: 0287 case GenericARM: 0288 case iOS: 0289 case GenericMIPS: 0290 case XL: 0291 return UseTailPaddingUnlessPOD03; 0292 0293 // AppleARM64 and WebAssembly use the C++11 POD rules. They do not honor 0294 // the Itanium exception about classes with over-large bitfields. 0295 case AppleARM64: 0296 case Fuchsia: 0297 case WebAssembly: 0298 case WatchOS: 0299 return UseTailPaddingUnlessPOD11; 0300 0301 // MSVC always allocates fields in the tail-padding of a base class 0302 // subobject, even if they're POD. 0303 case Microsoft: 0304 return AlwaysUseTailPadding; 0305 } 0306 llvm_unreachable("bad ABI kind"); 0307 } 0308 0309 friend bool operator==(const TargetCXXABI &left, const TargetCXXABI &right) { 0310 return left.getKind() == right.getKind(); 0311 } 0312 0313 friend bool operator!=(const TargetCXXABI &left, const TargetCXXABI &right) { 0314 return !(left == right); 0315 } 0316 }; 0317 0318 } // end namespace clang 0319 0320 #endif
| [ Source navigation ] | [ Diff markup ] | [ Identifier search ] | [ general search ] |
|
This page was automatically generated by the 2.3.7 LXR engine. The LXR team |
|