Home | History | Annotate | Download | only in Basic
      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.
     91   TargetCXXABI() : TheKind(GenericItanium) {}
     92 
     93   TargetCXXABI(Kind kind) : TheKind(kind) {}
     94 
     95   void set(Kind kind) {
     96     TheKind = kind;
     97   }
     98 
     99   Kind getKind() const { return TheKind; }
    100 
    101   /// \brief Does this ABI generally fall into the Itanium family of ABIs?
    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?
    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?
    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?
    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?
    146   bool hasDestructorVariants() const {
    147     return isItaniumFamily();
    148   }
    149 
    150   /// \brief Does this ABI allow virtual bases to be primary base classes?
    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.
    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   };
    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