summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/MicrosoftMangle.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* CFI: Introduce -fsanitize=cfi-icall flag.Peter Collingbourne2015-09-101-17/+0
| | | | | | | | | | This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
* [MS ABI] Number unnamed TagDecls which aren't externally visibleDavid Majnemer2015-09-021-1/+3
| | | | | | | | | | | | TagDecls (structs, enums, etc.) may have the same name for linkage purposes of one another; to disambiguate, we add a number to the mangled named. However, we didn't do this if the TagDecl has a pseudo-name for linkage purposes (it was defined alongside a DeclaratorDecl or a TypeNameDecl). This fixes PR24651. llvm-svn: 246659
* [MS ABI] Switch to the CRC implementation in LLVMDavid Majnemer2015-09-011-29/+5
| | | | | | | We now have an implementation of the CRC in LLVM's libSupport. Let's consolidate around that one. llvm-svn: 246591
* [MS ABI] Correctly mangle classes without names for linkage purposesDavid Majnemer2015-08-311-3/+10
| | | | | | | | | | | | | | | | A class without a name for linkage purposes gets a name along the lines of <unnamed-type-foo> where foo is either the name of a declarator which defined it (like a variable or field) or a typedef-name (like a typedef or alias-declaration). We handled the declarator case correctly but it would fall down during template instantiation if the declarator didn't share the tag's type. We failed to handle the typedef-name case at all. Instead, keep track of the association between the two and keep it up to date in the face of template instantiation. llvm-svn: 246469
* Remove and forbid raw_svector_ostream::flush() calls.Yaron Keren2015-08-131-1/+0
| | | | | | | | | | After r244870 flush() will only compare two null pointers and return, doing nothing but wasting run time. The call is not required any more as the stream and its SmallString are always in sync. Thanks to David Blaikie for reviewing. llvm-svn: 244928
* AST: Implement mangling support for function types without a prototype.Peter Collingbourne2015-08-071-4/+10
| | | | | | | | | | Function types without prototypes can arise when mangling a function type within an overloadable function in C. We mangle these as the absence of any parameter types (not even an empty parameter list). Differential Revision: http://reviews.llvm.org/D11848 llvm-svn: 244374
* [MS ABI] Create a mangling for extended vector typesDavid Majnemer2015-08-011-7/+3
| | | | | | Extended vector types are mangled just like normal vector types. llvm-svn: 243828
* [MS ABI] nullptr data member ptrs are mangled differently for classes vs fnsDavid Majnemer2015-07-021-3/+15
| | | | | | | | | | | It turns out that nullptr pointers to data members act differently in function templates vs class templates. Class templates use a variable width representation proportional to the number of fields needed to materialize it. Function templates always use a single '0' template parameter. However, using '0' all the time is problematic if the class uses single or multiple inheritance. In those cases, use -1. llvm-svn: 241251
* [MS ABI] Account for the virtual inheritance quirk when manglingDavid Majnemer2015-06-231-1/+8
| | | | | | | | | | | | Virtual inheritance member pointers are always relative to the vbindex, even when the member pointer doesn't point into a virtual base. This is corrected by adjusting the non-virtual offset backwards from the vbptr back to the top of the most derived class. While we performed this adjustment when manifesting member pointers as constants or when performing conversions, we didn't perform the adjustment when mangling them. llvm-svn: 240453
* [MS ABI] Rework member pointer conversionDavid Majnemer2015-06-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Member pointers in the MS ABI are made complicated due to the following: - Virtual methods in the most derived class (MDC) might live in a vftable in a virtual base. - There are four different representations of member pointer: single inheritance, multiple inheritance, virtual inheritance and the "most general" representation. - Bases might have a *more* general representation than classes which derived from them, a most surprising result. We believed that we could treat all member pointers as-if they were a degenerate case of the multiple inheritance model. This fell apart once we realized that implementing standard member pointers using this ABI requires referencing members with a non-zero vbindex. On a bright note, all but the virtual inheritance model operate rather similarly. The virtual inheritance member pointer representation awkwardly requires a virtual base adjustment in order to refer to entities in the MDC. However, the first virtual base might be quite far from the start of the virtual base. This means that we must add a negative non-virtual displacement. However, things get even more complicated. The most general representation interprets vbindex zero differently from the virtual inheritance model: it doesn't reference the vbtable at all. It turns out that this complexity can increase for quite some time: consider a derived to base conversion from the most general model to the multiple inheritance model... To manage this complexity we introduce a concept of "normalized" member pointer which allows us to treat all three models as the most general model. Then we try to figure out how to map this generalized member pointer onto the destination member pointer model. I've done my best to furnish the code with comments explaining why each adjustment is performed. This fixes PR23878. llvm-svn: 240384
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* CFI: Implement bitset emission for the Microsoft ABI.Peter Collingbourne2015-06-191-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang's control flow integrity implementation works by conceptually attaching "tags" (in the form of bitset entries) to each virtual table, identifying the names of the classes that the virtual table is compatible with. Under the Itanium ABI, it is simple to assign tags to virtual tables; they are simply the address points, which are available via VTableLayout. Because any overridden methods receive an entry in the derived class's virtual table, a check for an overridden method call can always be done by checking the tag of whichever derived class overrode the method call. The Microsoft ABI is a little different, as it does not directly use address points, and overrides in a derived class do not cause new virtual table entries to be added to the derived class; instead, the slot in the base class is reused, and the compiler needs to adjust the this pointer at the call site to (generally) the base class that initially defined the method. After the this pointer has been adjusted, we cannot check for the derived class's tag, as the virtual table may not be compatible with the derived class. So we need to determine which base class we have been adjusted to. Specifically, at each call site, we use ASTRecordLayout to identify the most derived class whose virtual table is laid out at the "this" pointer offset we are using to make the call, and check the virtual table for that tag. Because address point information is unavailable, we "reconstruct" it as follows: any virtual tables we create for a non-derived class receive a tag for that class, and virtual tables for a base class inside a derived class receive a tag for the base class, together with tags for any derived classes which are laid out at the same position as the derived class (and therefore have compatible virtual tables). Differential Revision: http://reviews.llvm.org/D10520 llvm-svn: 240117
* [MS ABI] Be a little more defensive wrt vector typesDavid Majnemer2015-06-011-14/+20
| | | | | | | | | We probably shouldn't say that all appropriately sized vector types are intel vector types (i.e. __m128, etc.) as they don't exist for all architectures. While this is largely academic, it'd save some debugging if we supported such a platform. llvm-svn: 238731
* [MS ABI] Implement restrict qualified referencesDavid Majnemer2015-05-261-65/+74
| | | | | | MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
* [MS ABI] Give __attribute__((overloadable)) functions pretty namesDavid Majnemer2015-05-181-2/+9
| | | | | | | | It turns out that there is a mangling for 'extern "C"', it's only used by MSVC in /clr mode. Co-opt this mangling so that extern "C" functions marked overloadable get demangled nicely. llvm-svn: 237548
* [MS ABI] Function encodings are always encoded in template argumentsDavid Majnemer2015-05-181-9/+14
| | | | llvm-svn: 237547
* Give isCompatibleWithMSVC a better interfaceDavid Majnemer2015-05-111-1/+2
| | | | | | | We now use an enum which maps the marketing name (almost always a year) to the major version number. llvm-svn: 236967
* [MS ABI] Make sure we number thread_local statics seperatelyDavid Majnemer2015-05-071-4/+2
| | | | | | | The thread_local variables need their own numbers, they can't share with the other static local variables. llvm-svn: 236774
* [MS ABI] Implement thread-safe initialization using the MSVC 2015 ABIDavid Majnemer2015-05-071-11/+18
| | | | | | | | | The MSVC 2015 ABI utilizes a rather straightforward adaptation of the algorithm found in the appendix of N2382. While we are here, implement support for emitting cleanups if an exception is thrown while we are intitializing a static local variable. llvm-svn: 236697
* Replace GetNumBytesInBuffer() in MicrosoftCXXNameMangler::mangleArgumentType ↵Yaron Keren2015-05-021-2/+2
| | | | | | | | | | | | | | | | | | | | | by tell(). Using GetNumBytesInBuffer() assumes that the stream was not flushed between the GetNumBytesInBuffer() calls, which may happen to be true or not, depending on stream policy. tell() always reports the correct stream location. Do note there are only two more uses of GetNumBytesInBuffer() in LLVM+clang, in lib/MC/MCAsmStreamer.cpp and lib/Target/R600/InstPrinter/AMDGPUInstPrinter.cpp. The former may be replacable by tell (needs testing) but while the later can not be immediatly replaced by tell() as it uses the absolute value of GetNumBytesInBuffer() rather than the real stream position. Both uses seems to depend upon flush policy and thus may not work correctly depending upon the stream behaviour. Going forward, GetNumBytesInBuffer() should probably be protected, non-accessible to raw_ostream clients. llvm-svn: 236389
* [MS ABI] Rephrase the mangling of array types in parametersDavid Majnemer2015-04-271-6/+5
| | | | | | Make the canonicalization of array types more consistent. llvm-svn: 235831
* [MS ABI] Add support for mangling VLA typesDavid Majnemer2015-04-231-13/+12
| | | | | | Treat a VLA type like an incomplete array type. llvm-svn: 235575
* [MS ABI] Treat ConstantArrayType like IncompleteArrayType in argsDavid Majnemer2015-04-231-4/+14
| | | | | | | | | | | | | Type backreferences for arguments use the DecayedType's original type. Because of this, arguments with the same canonical type with the same mangling would not backreference each other if one was a ConstantArrayType while the other was an IncompleteArrayType. Solve this by canonicalizing the ConstantArrayType to a suitable IncompleteArrayType. This fixes PR23325. llvm-svn: 235572
* Change range-based for-loops to be -Wrange-loop-analysis clean.Richard Trieu2015-04-151-1/+1
| | | | | | No functionality change. llvm-svn: 234964
* Reland r234613 (and follow-ups 234614, 234616, 234618)Reid Kleckner2015-04-141-0/+14
| | | | | | | The frameescape intrinsic cannot be inlined, so I fixed the inliner in r234937. This should address PR23216. llvm-svn: 234942
* Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.Nico Weber2015-04-131-14/+0
| | | | llvm-svn: 234789
* Revert r234786, it contained a bunch of stuff I did not mean to commit.Nico Weber2015-04-131-0/+14
| | | | llvm-svn: 234787
* Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.Nico Weber2015-04-131-14/+0
| | | | llvm-svn: 234786
* [SEH] Re-land r234532, but use internal linkage for all SEH helpersReid Kleckner2015-04-101-0/+14
| | | | | | | | | | Even though these symbols are in a comdat group, the Microsoft linker really wants them to have internal linkage. I'm planning to tweak the mangling in a follow-up change. This is a straight revert with a 1-line fix. llvm-svn: 234613
* Revert r234532 for a bit, it very likely caused http://crbug.com/475768Nico Weber2015-04-101-14/+0
| | | | llvm-svn: 234563
* [SEH] Outline finally blocks using the new variable capture supportReid Kleckner2015-04-091-0/+14
| | | | | | | | | | | | | | | WinEHPrepare was going to have to pattern match the control flow merge and split that the old lowering used, and that wasn't really feasible. Now we can teach WinEHPrepare to pattern match this, which is much simpler: %fp = call i8* @llvm.frameaddress(i32 0) call void @func(iN [01], i8* %fp) This prototype happens to match the prototype used by the Win64 SEH personality function, so this is really simple. llvm-svn: 234532
* [MS ABI] Rework .xdata HandlerType emissionDavid Majnemer2015-03-291-14/+7
| | | | | | | | | | Utilizing IMAGEREL relocations for synthetic IR constructs isn't valuable, just clutter. While we are here, simplify HandlerType names by making the numeric value for the 'adjective' part of the mangled name instead of appending '.const', etc. The old scheme made for very long global names and leads to wordy things like '.std_bad_alloc' llvm-svn: 233503
* MS ABI: Empty pack expansions had their mangling changed in 2013->2015David Majnemer2015-03-181-1/+5
| | | | | | | | | | We used to support the 2013 mangling and changed it to the more reasonable 2015 mangling. Let's make the mangling conditional on what version of MSVC is targeted. This fixes PR21888. llvm-svn: 232609
* MS ABI: Fix a couple of -Winconsistent-missing-override warningsJustin Bogner2015-03-171-1/+1
| | | | llvm-svn: 232559
* MS ABI: Emit HandlerMap entries for C++ catchDavid Majnemer2015-03-171-0/+18
| | | | | | | | | | | | | The HandlerMap describes, to the runtime, what sort of catches surround the try. In principle, this structure has to be emitted by the backend because only it knows the layout of the stack (the runtime needs to know where on the stack the destination of a copy lives, etc.) but there is some C++ specific information that the backend can't reason about. Stick this information in special LLVM globals with the relevant "const", "volatile", "reference" info mangled into the name. llvm-svn: 232538
* MS ABI: Mangle virtual member pointer thunks with the correct CCDavid Majnemer2015-03-141-1/+1
| | | | | | | | | | Virtual member pointers are implemented using a thunk. We assumed that the calling convention for this thunk was always __thiscall for 32-bit targets and __cdecl for 64-bit targets. However, this is not the case. Mangle in whichever calling convention is appropriate for this member function thunk. llvm-svn: 232254
* MS ABI: Generate default constructor closuresDavid Majnemer2015-03-131-1/+2
| | | | | | | | | | | | | | | | | | | | The MS ABI utilizes a compiler generated function called the "vector constructor iterator" to construct arrays of objects with non-trivial constructors/destructors. For this to work, the constructor must follow a specific calling convention. A thunk must be created if the default constructor has default arguments, is variadic or is otherwise incompatible. This thunk is called the default constructor closure. N.B. Default constructor closures are only generated if the default constructor is exported because clang itself does not utilize vector constructor iterators. Failing to export the default constructor closure will result in link/load failure if a translation unit compiled with MSVC is on the import side. Differential Revision: http://reviews.llvm.org/D8331 llvm-svn: 232229
* MS ABI: Implement copy-ctor closures, finish implementing throwDavid Majnemer2015-03-111-18/+71
| | | | | | | | | | | | | | | This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
* MS ABI: Mangle the location of the catchable type into it's nameDavid Majnemer2015-03-101-2/+17
| | | | | | | | Because the catchable type has a reference to its name, mangle the location to ensure that two catchable types with different locations are distinct. llvm-svn: 231819
* MS ABI: Insert copy-constructors into the CatchableTypeDavid Majnemer2015-03-061-8/+20
| | | | | | | | | | | | | | | | Find all unambiguous public classes of the exception object's class type and reference all of their copy constructors. Yes, this is not conforming but it is necessary in order to implement their ABI. This is because the copy constructor is actually referenced by the metadata describing which catch handlers are eligible to handle the exception object. N.B. This doesn't yet handle the copy constructor closure case yet, that work is ongoing. Differential Revision: http://reviews.llvm.org/D8101 llvm-svn: 231499
* MS ABI: Implement support for throwing a C++ exceptionDavid Majnemer2015-03-051-0/+39
| | | | | | | | | | | | | | | | | | | | | | | Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
* Implement Control Flow Integrity for virtual calls.Peter Collingbourne2015-02-201-0/+7
| | | | | | | | | | | | | | | This patch introduces the -fsanitize=cfi-vptr flag, which enables a control flow integrity scheme that checks that virtual calls take place using a vptr of the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst file. It also introduces the -fsanitize=cfi flag, which is currently a synonym for -fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented in Clang. Differential Revision: http://reviews.llvm.org/D7424 llvm-svn: 230055
* Initial support for Win64 SEH IR emissionReid Kleckner2015-01-221-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lowering looks a lot like normal EH lowering, with the exception that the exceptions are caught by executing filter expression code instead of matching typeinfo globals. The filter expressions are outlined into functions which are used in landingpad clauses where typeinfo would normally go. Major aspects that still need work: - Non-call exceptions in __try bodies won't work yet. The plan is to outline the __try block in the frontend to keep things simple. - Filter expressions cannot use local variables until capturing is implemented. - __finally blocks will not run after exceptions. Fixing this requires work in the LLVM SEH preparation pass. The IR lowering looks like this: // C code: bool safe_div(int n, int d, int *r) { __try { *r = normal_div(n, d); } __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) { return false; } return true; } ; LLVM IR: define i32 @filter(i8* %e, i8* %fp) { %ehptrs = bitcast i8* %e to i32** %ehrec = load i32** %ehptrs %code = load i32* %ehrec %matches = icmp eq i32 %code, i32 u0xC0000094 %matches.i32 = zext i1 %matches to i32 ret i32 %matches.i32 } define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) { %rr = invoke i32 @normal_div(i32 %n, i32 %d) to label %normal unwind to label %lpad normal: store i32 %rr, i32* %r ret i1 1 lpad: %ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*) %ehptr = extractvalue {i8*, i32} %ehvals, i32 0 %sel = extractvalue {i8*, i32} %ehvals, i32 1 %filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*)) %matches = icmp eq i32 %sel, %filter_sel br i1 %matches, label %eh.except, label %eh.resume eh.except: ret i1 false eh.resume: resume } Reviewers: rjmccall, rsmith, majnemer Differential Revision: http://reviews.llvm.org/D5607 llvm-svn: 226760
* MS ABI: Make the string mangling code more conciseDavid Majnemer2014-12-221-36/+10
| | | | | | No functional change intended. llvm-svn: 224696
* MS ABI: Fix mangling of unsigned int template paramsWill Wilson2014-12-111-1/+3
| | | | llvm-svn: 223999
* Simplify MicrosoftMangleContextImpl::shouldMangleStringLiteralDavid Majnemer2014-11-221-2/+1
| | | | | | No functionality changed. llvm-svn: 222610
* MS ABI: Mangle u8 string literalsDavid Majnemer2014-11-211-1/+2
| | | | | | UTF8 string literals are mangled just like ASCII string literals. llvm-svn: 222591
* MS ABI: Mangle char16_t and char32_t string literalsDavid Majnemer2014-11-211-10/+7
| | | | | | | | | | | | | | | | We previously had support for char and wchar_t string literals. VS 2015 added support for char16_t and char32_t. String literals must be mangled in the MS ABI in order for them to be deduplicated across translation units: their linker has no notion of mergeable section. Instead, they use the mangled name to make a COMDAT for the string literal; the COMDAT will merge with other COMDATs in other object files. This allows strings in object files generated by clang to get merged with strings in object files generated by MSVC. llvm-svn: 222564
* MS ABI: Mangle char16_t and char32_t typesDavid Majnemer2014-11-211-2/+2
| | | | | | | These mangling make clang more compatible with MSVC 2015. Correctly mangling char16_t and char32_t will take a little more work. llvm-svn: 222515
OpenPOWER on IntegriCloud