Coverage Report

Created: 2020-02-18 08:44

/Users/buildslave/jenkins/workspace/coverage/llvm-project/clang/include/clang/Basic/TargetCXXABI.h
Line
Count
Source (jump to first uncovered line)
1
//===--- TargetCXXABI.h - C++ ABI Target Configuration ----------*- C++ -*-===//
2
//
3
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
4
// See https://llvm.org/LICENSE.txt for license information.
5
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
6
//
7
//===----------------------------------------------------------------------===//
8
///
9
/// \file
10
/// Defines the TargetCXXABI class, which abstracts details of the
11
/// C++ ABI that we're targeting.
12
///
13
//===----------------------------------------------------------------------===//
14
15
#ifndef LLVM_CLANG_BASIC_TARGETCXXABI_H
16
#define LLVM_CLANG_BASIC_TARGETCXXABI_H
17
18
#include "llvm/Support/ErrorHandling.h"
19
20
namespace clang {
21
22
/// The basic abstraction for the target C++ ABI.
23
class TargetCXXABI {
24
public:
25
  /// The basic C++ ABI kind.
26
  enum Kind {
27
    /// The generic Itanium ABI is the standard ABI of most open-source
28
    /// and Unix-like platforms.  It is the primary ABI targeted by
29
    /// many compilers, including Clang and GCC.
30
    ///
31
    /// It is documented here:
32
    ///   http://www.codesourcery.com/public/cxx-abi/
33
    GenericItanium,
34
35
    /// The generic ARM ABI is a modified version of the Itanium ABI
36
    /// proposed by ARM for use on ARM-based platforms.
37
    ///
38
    /// These changes include:
39
    ///   - the representation of member function pointers is adjusted
40
    ///     to not conflict with the 'thumb' bit of ARM function pointers;
41
    ///   - constructors and destructors return 'this';
42
    ///   - guard variables are smaller;
43
    ///   - inline functions are never key functions;
44
    ///   - array cookies have a slightly different layout;
45
    ///   - additional convenience functions are specified;
46
    ///   - and more!
47
    ///
48
    /// It is documented here:
49
    ///    http://infocenter.arm.com
50
    ///                    /help/topic/com.arm.doc.ihi0041c/IHI0041C_cppabi.pdf
51
    GenericARM,
52
53
    /// The iOS ABI is a partial implementation of the ARM ABI.
54
    /// Several of the features of the ARM ABI were not fully implemented
55
    /// in the compilers that iOS was launched with.
56
    ///
57
    /// Essentially, the iOS ABI includes the ARM changes to:
58
    ///   - member function pointers,
59
    ///   - guard variables,
60
    ///   - array cookies, and
61
    ///   - constructor/destructor signatures.
62
    iOS,
63
64
    /// The iOS 64-bit ABI is follows ARM's published 64-bit ABI more
65
    /// closely, but we don't guarantee to follow it perfectly.
66
    ///
67
    /// It is documented here:
68
    ///    http://infocenter.arm.com
69
    ///                  /help/topic/com.arm.doc.ihi0059a/IHI0059A_cppabi64.pdf
70
    iOS64,
71
72
    /// WatchOS is a modernisation of the iOS ABI, which roughly means it's
73
    /// the iOS64 ABI ported to 32-bits. The primary difference from iOS64 is
74
    /// that RTTI objects must still be unique at the moment.
75
    WatchOS,
76
77
    /// The generic AArch64 ABI is also a modified version of the Itanium ABI,
78
    /// but it has fewer divergences than the 32-bit ARM ABI.
79
    ///
80
    /// The relevant changes from the generic ABI in this case are:
81
    ///   - representation of member function pointers adjusted as in ARM.
82
    ///   - guard variables  are smaller.
83
    GenericAArch64,
84
85
    /// The generic Mips ABI is a modified version of the Itanium ABI.
86
    ///
87
    /// At the moment, only change from the generic ABI in this case is:
88
    ///   - representation of member function pointers adjusted as in ARM.
89
    GenericMIPS,
90
91
    /// The WebAssembly ABI is a modified version of the Itanium ABI.
92
    ///
93
    /// The changes from the Itanium ABI are:
94
    ///   - representation of member function pointers is adjusted, as in ARM;
95
    ///   - member functions are not specially aligned;
96
    ///   - constructors and destructors return 'this', as in ARM;
97
    ///   - guard variables are 32-bit on wasm32, as in ARM;
98
    ///   - unused bits of guard variables are reserved, as in ARM;
99
    ///   - inline functions are never key functions, as in ARM;
100
    ///   - C++11 POD rules are used for tail padding, as in iOS64.
101
    ///
102
    /// TODO: At present the WebAssembly ABI is not considered stable, so none
103
    /// of these details is necessarily final yet.
104
    WebAssembly,
105
106
    /// The Fuchsia ABI is a modified version of the Itanium ABI.
107
    ///
108
    /// The relevant changes from the Itanium ABI are:
109
    ///   - constructors and destructors return 'this', as in ARM.
110
    Fuchsia,
111
112
    /// The Microsoft ABI is the ABI used by Microsoft Visual Studio (and
113
    /// compatible compilers).
114
    ///
115
    /// FIXME: should this be split into Win32 and Win64 variants?
116
    ///
117
    /// Only scattered and incomplete official documentation exists.
118
    Microsoft
119
  };
120
121
private:
122
  // Right now, this class is passed around as a cheap value type.
123
  // If you add more members, especially non-POD members, please
124
  // audit the users to pass it by reference instead.
125
  Kind TheKind;
126
127
public:
128
  /// A bogus initialization of the platform ABI.
129
66.3k
  TargetCXXABI() : TheKind(GenericItanium) {}
130
131
1.38M
  TargetCXXABI(Kind kind) : TheKind(kind) {}
132
133
68.8k
  void set(Kind kind) {
134
68.8k
    TheKind = kind;
135
68.8k
  }
136
137
19.8M
  Kind getKind() const { return TheKind; }
138
139
  /// Does this ABI generally fall into the Itanium family of ABIs?
140
583k
  bool isItaniumFamily() const {
141
583k
    switch (getKind()) {
142
572k
    case Fuchsia:
143
572k
    case GenericAArch64:
144
572k
    case GenericItanium:
145
572k
    case GenericARM:
146
572k
    case iOS:
147
572k
    case iOS64:
148
572k
    case WatchOS:
149
572k
    case GenericMIPS:
150
572k
    case WebAssembly:
151
572k
      return true;
152
572k
153
572k
    case Microsoft:
154
11.8k
      return false;
155
0
    }
156
0
    llvm_unreachable("bad ABI kind");
157
0
  }
158
159
  /// Is this ABI an MSVC-compatible ABI?
160
12.3M
  bool isMicrosoft() const {
161
12.3M
    switch (getKind()) {
162
12.2M
    case Fuchsia:
163
12.2M
    case GenericAArch64:
164
12.2M
    case GenericItanium:
165
12.2M
    case GenericARM:
166
12.2M
    case iOS:
167
12.2M
    case iOS64:
168
12.2M
    case WatchOS:
169
12.2M
    case GenericMIPS:
170
12.2M
    case WebAssembly:
171
12.2M
      return false;
172
12.2M
173
12.2M
    case Microsoft:
174
124k
      return true;
175
0
    }
176
0
    llvm_unreachable("bad ABI kind");
177
0
  }
178
179
  /// Are member functions differently aligned?
180
  ///
181
  /// Many Itanium-style C++ ABIs require member functions to be aligned, so
182
  /// that a pointer to such a function is guaranteed to have a zero in the
183
  /// least significant bit, so that pointers to member functions can use that
184
  /// bit to distinguish between virtual and non-virtual functions. However,
185
  /// some Itanium-style C++ ABIs differentiate between virtual and non-virtual
186
  /// functions via other means, and consequently don't require that member
187
  /// functions be aligned.
188
231k
  bool areMemberFunctionsAligned() const {
189
231k
    switch (getKind()) {
190
451
    case WebAssembly:
191
451
      // WebAssembly doesn't require any special alignment for member functions.
192
451
      return false;
193
231k
    case Fuchsia:
194
231k
    case GenericARM:
195
231k
    case GenericAArch64:
196
231k
    case GenericMIPS:
197
231k
      // TODO: ARM-style pointers to member functions put the discriminator in
198
231k
      //       the this adjustment, so they don't require functions to have any
199
231k
      //       special alignment and could therefore also return false.
200
231k
    case GenericItanium:
201
231k
    case iOS:
202
231k
    case iOS64:
203
231k
    case WatchOS:
204
231k
    case Microsoft:
205
231k
      return true;
206
0
    }
207
0
    llvm_unreachable("bad ABI kind");
208
0
  }
209
210
  /// Are arguments to a call destroyed left to right in the callee?
211
  /// This is a fundamental language change, since it implies that objects
212
  /// passed by value do *not* live to the end of the full expression.
213
  /// Temporaries passed to a function taking a const reference live to the end
214
  /// of the full expression as usual.  Both the caller and the callee must
215
  /// have access to the destructor, while only the caller needs the
216
  /// destructor if this is false.
217
1.84M
  bool areArgsDestroyedLeftToRightInCallee() const {
218
1.84M
    return isMicrosoft();
219
1.84M
  }
220
221
  /// Does this ABI have different entrypoints for complete-object
222
  /// and base-subobject constructors?
223
364k
  bool hasConstructorVariants() const {
224
364k
    return isItaniumFamily();
225
364k
  }
226
227
  /// Does this ABI allow virtual bases to be primary base classes?
228
196
  bool hasPrimaryVBases() const {
229
196
    return isItaniumFamily();
230
196
  }
231
232
  /// Does this ABI use key functions?  If so, class data such as the
233
  /// vtable is emitted with strong linkage by the TU containing the key
234
  /// function.
235
197k
  bool hasKeyFunctions() const {
236
197k
    return isItaniumFamily();
237
197k
  }
238
239
  /// Can an out-of-line inline function serve as a key function?
240
  ///
241
  /// This flag is only useful in ABIs where type data (for example,
242
  /// vtables and type_info objects) are emitted only after processing
243
  /// the definition of a special "key" virtual function.  (This is safe
244
  /// because the ODR requires that every virtual function be defined
245
  /// somewhere in a program.)  This usually permits such data to be
246
  /// emitted in only a single object file, as opposed to redundantly
247
  /// in every object file that requires it.
248
  ///
249
  /// One simple and common definition of "key function" is the first
250
  /// virtual function in the class definition which is not defined there.
251
  /// This rule works very well when that function has a non-inline
252
  /// definition in some non-header file.  Unfortunately, when that
253
  /// function is defined inline, this rule requires the type data
254
  /// to be emitted weakly, as if there were no key function.
255
  ///
256
  /// The ARM ABI observes that the ODR provides an additional guarantee:
257
  /// a virtual function is always ODR-used, so if it is defined inline,
258
  /// that definition must appear in every translation unit that defines
259
  /// the class.  Therefore, there is no reason to allow such functions
260
  /// to serve as key functions.
261
  ///
262
  /// Because this changes the rules for emitting type data,
263
  /// it can cause type data to be emitted with both weak and strong
264
  /// linkage, which is not allowed on all platforms.  Therefore,
265
  /// exploiting this observation requires an ABI break and cannot be
266
  /// done on a generic Itanium platform.
267
3.49M
  bool canKeyFunctionBeInline() const {
268
3.49M
    switch (getKind()) {
269
118k
    case Fuchsia:
270
118k
    case GenericARM:
271
118k
    case iOS64:
272
118k
    case WebAssembly:
273
118k
    case WatchOS:
274
118k
      return false;
275
118k
276
3.37M
    case GenericAArch64:
277
3.37M
    case GenericItanium:
278
3.37M
    case iOS:   // old iOS compilers did not follow this rule
279
3.37M
    case Microsoft:
280
3.37M
    case GenericMIPS:
281
3.37M
      return true;
282
0
    }
283
0
    llvm_unreachable("bad ABI kind");
284
0
  }
285
286
  /// When is record layout allowed to allocate objects in the tail
287
  /// padding of a base class?
288
  ///
289
  /// This decision cannot be changed without breaking platform ABI
290
  /// compatibility. In ISO C++98, tail padding reuse was only permitted for
291
  /// non-POD base classes, but that restriction was removed retroactively by
292
  /// DR 43, and tail padding reuse is always permitted in all de facto C++
293
  /// language modes. However, many platforms use a variant of the old C++98
294
  /// rule for compatibility.
295
  enum TailPaddingUseRules {
296
    /// The tail-padding of a base class is always theoretically
297
    /// available, even if it's POD.
298
    AlwaysUseTailPadding,
299
300
    /// Only allocate objects in the tail padding of a base class if
301
    /// the base class is not POD according to the rules of C++ TR1.
302
    UseTailPaddingUnlessPOD03,
303
304
    /// Only allocate objects in the tail padding of a base class if
305
    /// the base class is not POD according to the rules of C++11.
306
    UseTailPaddingUnlessPOD11
307
  };
308
218k
  TailPaddingUseRules getTailPaddingUseRules() const {
309
218k
    switch (getKind()) {
310
0
    // To preserve binary compatibility, the generic Itanium ABI has
311
0
    // permanently locked the definition of POD to the rules of C++ TR1,
312
0
    // and that trickles down to derived ABIs.
313
218k
    case GenericItanium:
314
218k
    case GenericAArch64:
315
218k
    case GenericARM:
316
218k
    case iOS:
317
218k
    case GenericMIPS:
318
218k
      return UseTailPaddingUnlessPOD03;
319
218k
320
218k
    // iOS on ARM64 and WebAssembly use the C++11 POD rules.  They do not honor
321
218k
    // the Itanium exception about classes with over-large bitfields.
322
218k
    case Fuchsia:
323
195
    case iOS64:
324
195
    case WebAssembly:
325
195
    case WatchOS:
326
195
      return UseTailPaddingUnlessPOD11;
327
195
328
195
    // MSVC always allocates fields in the tail-padding of a base class
329
195
    // subobject, even if they're POD.
330
195
    case Microsoft:
331
0
      return AlwaysUseTailPadding;
332
0
    }
333
0
    llvm_unreachable("bad ABI kind");
334
0
  }
335
336
1.38M
  friend bool operator==(const TargetCXXABI &left, const TargetCXXABI &right) {
337
1.38M
    return left.getKind() == right.getKind();
338
1.38M
  }
339
340
1.33M
  friend bool operator!=(const TargetCXXABI &left, const TargetCXXABI &right) {
341
1.33M
    return !(left == right);
342
1.33M
  }
343
};
344
345
}  // end namespace clang
346
347
#endif