summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/COFF
Commit message (Collapse)AuthorAgeFilesLines
...
* DebugInfo: elide type index entries for synthetic typesSaleem Abdulrasool2017-05-031-0/+55
| | | | | | | | | | | | | | Compiler emitted synthetic types may not have an associated DIFile (translation unit). In such a case, when generating CodeView debug type information, we would attempt to compute an absolute filepath which would result in a segfault due to a NULL DIFile*. If there is no source file associated with the type, elide the type index entry for the type and record the type information. This actually results in higher fidelity debug information than clang/C2 as of this writing. Resolves PR32668! llvm-svn: 302085
* Remove line and file from DINamespace.Adrian Prantl2017-04-282-3/+3
| | | | | | | | | | | | | | Fixes the issue highlighted in http://lists.llvm.org/pipermail/cfe-dev/2014-June/037500.html. The DW_AT_decl_file and DW_AT_decl_line attributes on namespaces can prevent LLVM from uniquing types that are in the same namespace. They also don't carry any meaningful information. rdar://problem/17484998 Differential Revision: https://reviews.llvm.org/D32648 llvm-svn: 301706
* Print complete DIExpressions in the assembler output DEBUG_VALUE comments.Adrian Prantl2017-04-251-12/+12
| | | | | | The previous code was complex, incorrect, and couldn't print everything. llvm-svn: 301333
* [codeview] Don't assert when the user violates the ODRReid Kleckner2017-03-241-0/+100
| | | | | | | | | | If we have an array of a user-defined aggregates for which there was an ODR violation, then the array size will not necessarily match the number of elements times the size of the element. Fixes PR32383 llvm-svn: 298750
* MC/COFF: Do not emit forward associative section referenceds.Rui Ueyama2017-02-172-2/+2
| | | | | | | | | | | | | | | | MSVC link.exe cannot handle associative sections that refer later sections in the section header. Technically, such COFF object doesn't violate the Microsoft COFF spec, as the spec doesn't say anything about that, but still we should avoid doing that to make it compatible with MS tools. This patch assigns smaller section numbers to non-associative sections and larger numbers to associative sections. This should resolve the compatibility issue. Differential Revision: https://reviews.llvm.org/D30080 llvm-svn: 295464
* Refactor DebugHandlerBase a bit to common non-debug-having-function filteringDavid Blaikie2017-02-161-1/+1
| | | | llvm-svn: 295354
* Renumber testcase metadata nodes after r290153.Adrian Prantl2016-12-2221-6542/+6605
| | | | | | | | | | | | | This patch renumbers the metadata nodes in debug info testcases after https://reviews.llvm.org/D26769. This is a separate patch because it causes so much churn. This was implemented with a python script that pipes the testcases through llvm-as - | llvm-dis - and then goes through the original and new output side-by side to insert all comments at a close-enough location. Differential Revision: https://reviews.llvm.org/D27765 llvm-svn: 290292
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-2021-41/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-1621-41/+41
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-1621-41/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-1621-41/+41
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-1621-41/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* [DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operationAdrian Prantl2016-12-051-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | so we can stop using DW_OP_bit_piece with the wrong semantics. The entire back story can be found here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's offset field to mean the offset into the source variable rather than the offset into the location at the top the DWARF expression stack. In order to be able to fix this in a subsequent patch, this patch introduces a dedicated DW_OP_LLVM_fragment operation with the semantics that we used to apply to DW_OP_bit_piece, which is what we actually need while inside of LLVM. This patch is complete with a bitcode upgrade for expressions using the old format. It does not yet fix the DWARF backend to use DW_OP_bit_piece correctly. Implementation note: We discussed several options for implementing this, including reserving a dedicated field in DIExpression for the fragment size and offset, but using an custom operator at the end of the expression works just fine and is more efficient because we then only pay for it when we need it. Differential Revision: https://reviews.llvm.org/D27361 rdar://problem/29335809 llvm-svn: 288683
* [AsmPrinter] Enable codeview for windows-itaniumShoaib Meenai2016-11-211-0/+4
| | | | | | | | | | Enable codeview emission for windows-itanium targets. Co-opt an existing test (which is derived from a C source file and should therefore be identical across the Itanium and MS ABIs). Differential Revision: https://reviews.llvm.org/D26693 llvm-svn: 287567
* Emit S_COMPILE3 record once per TU rather than once per functionAdrian McCarthy2016-11-025-217/+76
| | | | | | This has some ripple effects in several tests. llvm-svn: 285862
* Reapply: "Remove debug location from common tail when tail-merging"Robert Lougher2016-10-261-6/+4
| | | | | | | | | | | | | | | | This reapplies revision 285093. Original commit message: The branch folding pass tail merges blocks into a common-tail. However, the tail retains the debug information from one of the original inputs to the merge (chosen randomly). This is a problem for sampled-based PGO, as hits on the common-tail will be attributed to whichever block was chosen, irrespective of which path was actually taken to the common-tail. This patch fixes the issue by nulling the debug location for the common-tail. Differential Revision: https://reviews.llvm.org/D25742 llvm-svn: 285212
* [codeview] support emitting indirect virtual base class informationBob Haarman2016-10-251-224/+54
| | | | | | | | | | | | | | | | Summary: Fixes PR28281. MSVC lists indirect virtual base classes in the field list of a class, using LF_IVBCLASS records. This change makes LLVM emit such records when processing DW_TAG_inheritance tags with the DIFlagVirtual and (newly introduced) DIFlagIndirect tags. Reviewers: rnk, ruiu, zturner Differential Revision: https://reviews.llvm.org/D25578 llvm-svn: 285130
* revert: "Remove debug location from common tail when tail-merging"Robert Lougher2016-10-251-4/+6
| | | | | | | | This reverts r285093, as it caused unexpected buildbot failures on clang-ppc64le-linux, clang-ppc64be-linux, clang-ppc64be-linux-multistage and clang-ppc64be-linux-lnt. Failing test ubsan/TestCases/TypeCheck/vptr.cpp. llvm-svn: 285110
* Remove debug location from common tail when tail-mergingRobert Lougher2016-10-251-6/+4
| | | | | | | | | | | | | | The branch folding pass tail merges blocks into a common-tail. However, the tail retains the debug information from one of the original inputs to the merge (chosen randomly). This is a problem for sampled-based PGO, as hits on the common-tail will be attributed to whichever block was chosen, irrespective of which path was actually taken to the common-tail. This patch fixes the issue by nulling the debug location for the common-tail. Differential Revision: https://reviews.llvm.org/D25742 llvm-svn: 285093
* Using branch probability to guide critical edge splitting.Dehao Chen2016-10-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The original heuristic to break critical edge during machine sink is relatively conservertive: when there is only one instruction sinkable to the critical edge, it is likely that the machine sink pass will not break the critical edge. This leads to many speculative instructions executed at runtime. However, with profile info, we could model the splitting benefits: if the critical edge has 50% taken rate, it would always be beneficial to split the critical edge to avoid the speculated runtime instructions. This patch uses profile to guide critical edge splitting in machine sink pass. The performance impact on speccpu2006 on Intel sandybridge machines: spec/2006/fp/C++/444.namd 25.3 +0.26% spec/2006/fp/C++/447.dealII 45.96 -0.10% spec/2006/fp/C++/450.soplex 41.97 +1.49% spec/2006/fp/C++/453.povray 36.83 -0.96% spec/2006/fp/C/433.milc 23.81 +0.32% spec/2006/fp/C/470.lbm 41.17 +0.34% spec/2006/fp/C/482.sphinx3 48.13 +0.69% spec/2006/int/C++/471.omnetpp 22.45 +3.25% spec/2006/int/C++/473.astar 21.35 -2.06% spec/2006/int/C++/483.xalancbmk 36.02 -2.39% spec/2006/int/C/400.perlbench 33.7 -0.17% spec/2006/int/C/401.bzip2 22.9 +0.52% spec/2006/int/C/403.gcc 32.42 -0.54% spec/2006/int/C/429.mcf 39.59 +0.19% spec/2006/int/C/445.gobmk 26.98 -0.00% spec/2006/int/C/456.hmmer 24.52 -0.18% spec/2006/int/C/458.sjeng 28.26 +0.02% spec/2006/int/C/462.libquantum 55.44 +3.74% spec/2006/int/C/464.h264ref 46.67 -0.39% geometric mean +0.20% Manually checked 473 and 471 to verify the diff is in the noise range. Reviewers: rengolin, davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24818 llvm-svn: 284757
* DebugInfo: preparation to implement DW_AT_alignmentVictor Leschuk2016-10-201-19/+19
| | | | | | | | | | | | - Add alignment attribute to DIVariable family - Modify bitcode format to match new DIVariable representation - Update tests to match these changes (also add bitcode upgrade test) - Expect that frontend passes non-zero align value only when it is not default (was forcibly aligned by alignas()/_Alignas()/__atribute__(aligned()) Differential Revision: https://reviews.llvm.org/D25073 llvm-svn: 284678
* Revert r284545 again as the regression in ppc still exists. There is bug in ↵Dehao Chen2016-10-191-3/+3
| | | | | | | | MBPI exposed by th patch. Also update the section.ll to fix non-x86 failure. llvm-svn: 284563
* Using branch probability to guide critical edge splitting.Dehao Chen2016-10-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The original heuristic to break critical edge during machine sink is relatively conservertive: when there is only one instruction sinkable to the critical edge, it is likely that the machine sink pass will not break the critical edge. This leads to many speculative instructions executed at runtime. However, with profile info, we could model the splitting benefits: if the critical edge has 50% taken rate, it would always be beneficial to split the critical edge to avoid the speculated runtime instructions. This patch uses profile to guide critical edge splitting in machine sink pass. The performance impact on speccpu2006 on Intel sandybridge machines: spec/2006/fp/C++/444.namd 25.3 +0.26% spec/2006/fp/C++/447.dealII 45.96 -0.10% spec/2006/fp/C++/450.soplex 41.97 +1.49% spec/2006/fp/C++/453.povray 36.83 -0.96% spec/2006/fp/C/433.milc 23.81 +0.32% spec/2006/fp/C/470.lbm 41.17 +0.34% spec/2006/fp/C/482.sphinx3 48.13 +0.69% spec/2006/int/C++/471.omnetpp 22.45 +3.25% spec/2006/int/C++/473.astar 21.35 -2.06% spec/2006/int/C++/483.xalancbmk 36.02 -2.39% spec/2006/int/C/400.perlbench 33.7 -0.17% spec/2006/int/C/401.bzip2 22.9 +0.52% spec/2006/int/C/403.gcc 32.42 -0.54% spec/2006/int/C/429.mcf 39.59 +0.19% spec/2006/int/C/445.gobmk 26.98 -0.00% spec/2006/int/C/456.hmmer 24.52 -0.18% spec/2006/int/C/458.sjeng 28.26 +0.02% spec/2006/int/C/462.libquantum 55.44 +3.74% spec/2006/int/C/464.h264ref 46.67 -0.39% geometric mean +0.20% Manually checked 473 and 471 to verify the diff is in the noise range. Reviewers: rengolin, davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24818 llvm-svn: 284545
* revert r284541.Dehao Chen2016-10-181-3/+3
| | | | llvm-svn: 284544
* Using branch probability to guide critical edge splitting.Dehao Chen2016-10-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The original heuristic to break critical edge during machine sink is relatively conservertive: when there is only one instruction sinkable to the critical edge, it is likely that the machine sink pass will not break the critical edge. This leads to many speculative instructions executed at runtime. However, with profile info, we could model the splitting benefits: if the critical edge has 50% taken rate, it would always be beneficial to split the critical edge to avoid the speculated runtime instructions. This patch uses profile to guide critical edge splitting in machine sink pass. The performance impact on speccpu2006 on Intel sandybridge machines: spec/2006/fp/C++/444.namd 25.3 +0.26% spec/2006/fp/C++/447.dealII 45.96 -0.10% spec/2006/fp/C++/450.soplex 41.97 +1.49% spec/2006/fp/C++/453.povray 36.83 -0.96% spec/2006/fp/C/433.milc 23.81 +0.32% spec/2006/fp/C/470.lbm 41.17 +0.34% spec/2006/fp/C/482.sphinx3 48.13 +0.69% spec/2006/int/C++/471.omnetpp 22.45 +3.25% spec/2006/int/C++/473.astar 21.35 -2.06% spec/2006/int/C++/483.xalancbmk 36.02 -2.39% spec/2006/int/C/400.perlbench 33.7 -0.17% spec/2006/int/C/401.bzip2 22.9 +0.52% spec/2006/int/C/403.gcc 32.42 -0.54% spec/2006/int/C/429.mcf 39.59 +0.19% spec/2006/int/C/445.gobmk 26.98 -0.00% spec/2006/int/C/456.hmmer 24.52 -0.18% spec/2006/int/C/458.sjeng 28.26 +0.02% spec/2006/int/C/462.libquantum 55.44 +3.74% spec/2006/int/C/464.h264ref 46.67 -0.39% geometric mean +0.20% Manually checked 473 and 471 to verify the diff is in the noise range. Reviewers: rengolin, davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24818 llvm-svn: 284541
* Truncate long names in type recordsReid Kleckner2016-10-131-0/+40
| | | | | | | | | In the MS ABI, the frontend is supposed to MD5 such pathologically long names. LLVM should still defend itself from long names, though. Fixes part of PR29098. llvm-svn: 284136
* [codeview] Truncate records to maximum record size near 64KBReid Kleckner2016-10-051-0/+43
| | | | | | | | | | | | If we don't truncate, LLVM asserts when the label difference doesn't fit in a 16 bit field. This patch truncates two kinds of data: trailing null terminated names in symbol records, and inline line tables. The inline line table test that I have is too large (many MB), so I'm not checking it in. Hopefully fixes PR28264. llvm-svn: 283403
* [codeview] Translate bitpiece metadata to DEFRANGE_SUBFIELD* recordsReid Kleckner2016-10-051-0/+429
| | | | | | | | | | | | | This allows LLVM to describe locations of aggregate variables that have been split by SROA. Fixes PR29141 Reviewers: amccarth, majnemer Differential Revision: https://reviews.llvm.org/D25253 llvm-svn: 283388
* [codeview] Use character types for all byte-sized integer typesReid Kleckner2016-09-291-0/+55
| | | | | | | | | | | | | | | The VS debugger doesn't appear to understand the 0x68 or 0x69 type indices, which were probably intended for use on a platform where a C 'int' is 8 bits. So, use the character types instead. Clang was already using the character types because '[u]int8_t' is usually defined in terms of 'char'. See the Rust issue for screenshots of what VS does: https://github.com/rust-lang/rust/issues/36646 Fixes PR30552 llvm-svn: 282739
* Teach LiveDebugValues about lexical scopes.Adrian Prantl2016-09-281-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This addresses PR26055 LiveDebugValues is very slow. Contrary to the old LiveDebugVariables pass LiveDebugValues currently doesn't look at the lexical scopes before inserting a DBG_VALUE intrinsic. This means that we often propagate DBG_VALUEs much further down than necessary. This is especially noticeable in large C++ functions with many inlined method calls that all use the same "this"-pointer. For example, in the following code it makes no sense to propagate the inlined variable a from the first inlined call to f() into any of the subsequent basic blocks, because the variable will always be out of scope: void sink(int a); void __attribute((always_inline)) f(int a) { sink(a); } void foo(int i) { f(i); if (i) f(i); f(i); } This patch reuses the LexicalScopes infrastructure we have for LiveDebugVariables to take this into account. The effect on compile time and memory consumption is quite noticeable: I tested a benchmark that is a large C++ source with an enormous amount of inlined "this"-pointers that would previously eat >24GiB (most of them for DBG_VALUE intrinsics) and whose compile time was dominated by LiveDebugValues. With this patch applied the memory consumption is 1GiB and 1.7% of the time is spent in LiveDebugValues. https://reviews.llvm.org/D24994 Thanks to Daniel Berlin and Keith Walker for reviewing! llvm-svn: 282611
* [X86] Optimization for replacing LEA with MOV at frame index elimination timeZvi Rackover2016-09-261-3/+3
| | | | | | | | | | | | | | | Summary: Replace a LEA instruction of the form 'lea (%esp), %ebx' --> 'mov %esp, %ebx' MOV is preferable over LEA because usually there are more issue-slots available to execute MOVs than LEAs. Latest processors also support zero-latency MOVs. Fixes pr29022. Reviewers: hfinkel, delena, igorb, myatsina, mkuper Differential Revision: https://reviews.llvm.org/D24705 llvm-svn: 282385
* Emit S_COMPILE3 CodeView recordAdrian McCarthy2016-09-207-63/+84
| | | | | | | | | | CodeView has an S_COMPILE3 record to identify the compiler and source language of the compiland. This record comes first in the debug$S section for the compiland. The debuggers rely on this record to know the source language of the code. There was a little test fallout from introducing a new record into the symbols subsection. Differential Revision: https://reviews.llvm.org/D24317 llvm-svn: 281990
* [codeview] Optimize the size of defranges with gapsReid Kleckner2016-09-151-0/+174
| | | | | | | | | For small, discontiguous local variable regions, CodeView can use a single defrange record with a gap, rather than having two defrange records. I expect that this optimization will only have a minor impact on debug info size. llvm-svn: 281664
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-1319-74/+74
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* [codeview] Don't assert if the array element type is incompleteReid Kleckner2016-09-091-0/+140
| | | | | | | | | This can happen when the frontend knows the debug info will be emitted somewhere else. Usually this happens for dynamic classes with out of line constructors or key functions, but it can also happen when modules are enabled. llvm-svn: 281060
* Win64: Don't use REX prefix for direct tail callsHans Wennborg2016-09-081-1/+1
| | | | | | | | | | The REX prefix should be used on indirect jmps, but not direct ones. For direct jumps, the unwinder looks at the offset to determine if it's inside the current function. Differential Revision: https://reviews.llvm.org/D24359 llvm-svn: 281003
* [codeview] Add new directives to record inlined call site line infoReid Kleckner2016-09-074-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously we were trying to represent this with the "contains" list of the .cv_inline_linetable directive, which was not enough information. Now we directly represent the chain of inlined call sites, so we know what location to emit when we encounter a .cv_loc directive of an inner inlined call site while emitting the line table of an outer function or inlined call site. Fixes PR29146. Also fixes PR29147, where we would crash when .cv_loc directives crossed sections. Now we write down the section of the first .cv_loc directive, and emit an error if any other .cv_loc directive for that function is in a different section. Also fixes issues with discontiguous inlined source locations, like in this example: volatile int unlikely_cond = 0; extern void __declspec(noreturn) abort(); __forceinline void f() { if (!unlikely_cond) abort(); } int main() { unlikely_cond = 0; f(); unlikely_cond = 0; } Previously our tables gave bad location information for the 'abort' call, and the debugger wouldn't snow the inlined stack frame for 'f'. It is important to emit good line tables for this code pattern, because it comes up whenever an asan bug occurs in an inlined function. The __asan_report* stubs are generally placed after the normal function epilogue, leading to discontiguous regions of inlined code. Reviewers: majnemer, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24014 llvm-svn: 280822
* [codeview] Use the correct max CV record length of 0xFF00Reid Kleckner2016-09-021-8/+8
| | | | | | | | | | | Previously we were splitting our records at 0xFFFF bytes, which the Microsoft tools don't like. Should fix failure on the new Windows self-host buildbot. This length appears in microsoft-pdb/PDB/dbi/dbiimpl.h llvm-svn: 280522
* [codeview] Emit vtable shape informationReid Kleckner2016-08-312-42/+548
| | | | | | | | | | | | | The shape of the vtable is passed down as the size of the __vtbl_ptr_type. This special pointer type appears both as the pointee type of the vptr type, and by itself in every dynamic class. For classes with multiple vtables, only the shape of the primary vftable is included, as the shape of all secondary vftables will be the same as in the base class. Fixes PR28150 llvm-svn: 280254
* Resubmit "Write the TPI stream from a PDB to Yaml."Zachary Turner2016-08-185-0/+18
| | | | | | | | The original patch was breaking some buildbots due to an incorrect ordering of function definitions which caused some compilers to recognize a definition but others to not. llvm-svn: 279089
* Revert "Write the TPI stream from a PDB to Yaml."Justin Bogner2016-08-165-18/+0
| | | | | | | | | This is hitting a "use of undeclared identifier 'skipPadding' error locally and on some bots. This reverts r278869. llvm-svn: 278871
* Write the TPI stream from a PDB to Yaml.Zachary Turner2016-08-165-0/+18
| | | | | | | Reviewed By: ruiu, rnk Differential Revision: https://reviews.llvm.org/D23226 llvm-svn: 278869
* [CodeView] Don't crash on functions without subprogramsDavid Majnemer2016-07-282-1/+45
| | | | | | | | | A function may have instructions annotated with debug info without having a subprogram. This fixes PR28747. llvm-svn: 276956
* [codeview] Shrink inlined call site line info tablesReid Kleckner2016-07-142-11/+173
| | | | | | | | | | | For a fully inlined call chain like a -> b -> c -> d, we were emitting line info for 'd' 3 separate times: once for d's actual InlineSite line table, and twice for 'b' and 'c'. This is particularly inefficient when all these functions are in different headers, because now we need to encode the file change. Windbg was coping with our suboptimal output, so this should not be noticeable from the debugger. llvm-svn: 275502
* [codeview] Improved array type support.Amjad Aboud2016-07-121-0/+218
| | | | | | | | | | | | Added support for: 1. Multi dimension array. 2. Array of structure type, which previously was declared incompletely. 3. Dynamic size array. 4. Array where element type is a typedef, volatile or constant (this should resolve PR28311). Differential Revision: http://reviews.llvm.org/D21526 llvm-svn: 275167
* [CodeView] Implement support for thread-local variablesDavid Majnemer2016-07-071-5/+4
| | | | llvm-svn: 274734
* [CodeView] Emit an appropriate symbol kind for globalsDavid Majnemer2016-07-063-7/+16
| | | | | | | We emitted debug info for globals/functions as if they all had external linkage. Instead, emit local symbol records when appropriate. llvm-svn: 274676
* [CodeView] Unions are always sealedDavid Majnemer2016-07-061-1/+2
| | | | | | | It is impossible to inherit from a union. We are missing a way to represent this in IR for classes/structs... llvm-svn: 274675
* Retry: "Emit CodeView type records for nested classes."Adrian McCarthy2016-07-061-0/+98
| | | | | | | | | | Now with a corrected test to account for a recently supported properties bit in the debug info of a struct. Original review: http://reviews.llvm.org/D21939 This reverts commit 970c3fd497a28d25dd69526eb52594a696c37968. llvm-svn: 274661
* Revert "Emit CodeView type records for nested classes."Adrian McCarthy2016-07-061-98/+0
| | | | | | This reverts commit 256b29322c827a2d94da56468c936596f5509032. llvm-svn: 274632
OpenPOWER on IntegriCloud