summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/MicrosoftRTTI.cpp
Commit message (Collapse)AuthorAgeFilesLines
* CodeGen: Refactor RTTI emissionDavid Majnemer2014-07-071-529/+0
| | | | | | | | | | | | | | | | | | | | | | | Let's not expose ABI specific minutia inside of CodeGenModule and Type. Instead, let's abstract it through CXXABI. This gets rid of: CodeGenModule::getCompleteObjectLocator, CodeGenModule::EmitFundamentalTypeDescriptor{s,}, CodeGenModule::getMSTypeDescriptor, CodeGenModule::getMSCompleteObjectLocator, CGCXXABI::shouldRTTIBeUnique, CGCXXABI::classifyRTTIUniqueness. CGRTTI was *almost* entirely centered around providing Itanium-style RTTI information. Instead of providing interfaces that only it consumes, move it to the ItaniumCXXABI implementation file. This allows it to have access to Itanium-specific implementation details without providing useless expansion points for the Microsoft ABI side. Differential Revision: http://reviews.llvm.org/D4261 llvm-svn: 212435
* MS ABI: Get linkage of RTTI data correctDavid Majnemer2014-07-031-2/+17
| | | | | | | | | | | | | | | | | The Itanium rules are not appropriate for the MS ABI. RTTI data is _never_ imported and thus is never available_externally. It is either internal (if the type's linkage is internal) or linkonce_odr. This also means that classes which inherit from dllimport'd bases force their translation unit to duplicate the entirety of the RTTI data of that base. Interestingly, the complete object locator can never be referenced by translation units which import the class. This fixes PR20106. llvm-svn: 212256
* Driver: Handle /GR- in a compatible way with MSVCDavid Majnemer2014-07-011-1/+1
| | | | | | | | | | | | | | | | | There are slight differences between /GR- and -fno-rtti which made mapping one to the other inappropriate. -fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related information for the v-table. /GR- does not generate complete object locators and thus will not reference them in vftables. However, constructs like dynamic_cast and typeid are permitted. This should bring our implementation of RTTI up to semantic parity with MSVC modulo bugs. llvm-svn: 212138
* MS ABI: Reference MSVC RTTI from the VFTableDavid Majnemer2014-07-011-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pointer for a class's RTTI data comes right before the VFTable but has no name. To be properly compatible with this, we do the following: * Create a single GlobalVariable which holds the contents of the VFTable _and_ the pointer to the RTTI data. * Create a GlobalAlias, with appropriate linkage/visibility, that points just after the RTTI data pointer. This ensures that the VFTable symbol will always refer to VFTable data. * Create a Comdat with a "Largest" SelectionKind and stick the private GlobalVariable in it. By transitivity, the GlobalAlias will be a member of the Comdat group. Using "Largest" ensures that foreign definitions without an RTTI data pointer will _not_ be chosen in the final linked image. Whether or not we emit RTTI data depends on several things: * The -fno-rtti flag implies that we should never not emit a pointer to RTTI data before the VFTable. * __declspec(dllimport) brings in the VFTable from a remote DLL. Use an available_externally GlobalVariable to provide a local definition of the VFTable. This means that we won't have any available_externally definitions of things like complete object locators. This is acceptable because they are never directly referenced. To my knowledge, this completes the implementation of MSVC RTTI code generation. Further semantic work should be done to properly support /GR-. llvm-svn: 212125
* Remove llvm:: from uses of ArrayRef.Craig Topper2014-06-281-3/+3
| | | | llvm-svn: 211987
* MS ABI: Implement x86_64 RTTIDavid Majnemer2014-06-161-18/+81
| | | | | | | | | | | | | | | | | Summary: The RTTI scheme for x86_64 is largely the same as the one for i386. Differences are largely limited to avoiding load-time relocations by replacing pointers to RTTI metadata with the difference of that data relative to the load address of the module. Interestingly, this precludes the possibility of successfully using RTTI data from another DLL. The ImageBase reference is always relative to the current DLL. Differential Revision: http://reviews.llvm.org/D4148 llvm-svn: 211041
* [C++11] Use 'nullptr'.Craig Topper2014-06-091-7/+9
| | | | llvm-svn: 210448
* Fix typosAlp Toker2014-06-061-6/+6
| | | | llvm-svn: 210328
* [MS-ABI] Silence warning from r209523Warren Hunt2014-05-231-1/+1
| | | | | | no functional change. llvm-svn: 209525
* [MS-ABI] Implements MS-compatible RTTIWarren Hunt2014-05-231-0/+447
Enables the emission of MS-compatible RTTI data structures for use with typeid, dynamic_cast and exceptions. Does not implement dynamic_cast or exceptions. As an artiface, typeid works in some cases but proper support an testing will coming in a subsequent patch. majnemer has fuzzed the results. Test cases included. Differential Revision: http://reviews.llvm.org/D3833 llvm-svn: 209523
OpenPOWER on IntegriCloud