Back to home page

EIC code displayed by LXR

 
 

    


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