summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-16119-216/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-16119-285/+216
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-16119-216/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* DebugInfo: Make a Generic test case actually generic (remove datalayout/triple)David Blaikie2016-12-151-7/+0
| | | | llvm-svn: 289893
* DebugInfo: Emit ranges for functions with DISubprograms but lacking ↵David Blaikie2016-12-152-1/+43
| | | | | | | | | locations on any instructions This seems more consistent, and helps tidy up/simplify some other code in this change. llvm-svn: 289889
* Revert "[SimplifyCFG] In sinkLastInstruction correctly set debugloc of ↵Robert Lougher2016-12-151-70/+0
| | | | | | | | common inst" Reverting as it is causing buildbot failures (address sanitizer). llvm-svn: 289833
* [SimplifyCFG] In sinkLastInstruction correctly set debugloc of "common" inst Robert Lougher2016-12-151-0/+70
| | | | | | | | | | | Simplify CFG will try to sink the last instruction in a series of basic blocks, creating a "common" instruction in the successor block (sinkLastInstruction). When it does this, the debug location of the single instruction should be the merged debug locations of the commoned instructions. Differential Revision: https://reviews.llvm.org/D27590 llvm-svn: 289828
* [InstCombine] Folding of a compare with RHS const should merge debug locationsRobert Lougher2016-12-141-0/+51
| | | | | | | | | | | | | If all the operands to a phi node are compares that have a RHS constant, instcombine will try to pull them through the phi node, combining them into a single operation. When it does this, the debug location of the new op should be the merged debug locations of the phi node arguments. Patch 8 of 8 for D26256. Folding of a compare that has a RHS constant. Differential Revision: https://reviews.llvm.org/D26256 llvm-svn: 289704
* [InstCombine] Folding of a binop with RHS const should merge the debug locationsRobert Lougher2016-12-141-0/+49
| | | | | | | | | | | | | If all the operands to a phi node are a binop with a RHS constant, instcombine will try to pull them through the phi node, combining them into a single operation. When it does this, the debug location of the new op should be the merged debug locations of the phi node arguments. Patch 7 of 8 for D26256. Folding of a binop with RHS constant. Differential Revision: https://reviews.llvm.org/D26256 llvm-svn: 289699
* [InstCombine] When folding casts through a phi node merge the debug locationsRobert Lougher2016-12-141-0/+47
| | | | | | | | | | | | | If all the operands to a phi node are a cast, instcombine will try to pull them through the phi node, combining them into a single cast. When it does this, the debug location of the new cast should be the merged debug locations of the phi node arguments. Patch 6 of 8 for D26256. Folding of a cast operation. Differential Revision: https://reviews.llvm.org/D26256 llvm-svn: 289693
* [InstCombine] Folding loads through a phi node should merge the debug locationsRobert Lougher2016-12-141-0/+51
| | | | | | | | | | | | | If all the operands to a phi node are a load, instcombine will try to pull them through the phi node, combining them into a single load. When it does this, the debug location of the new load should be the merged debug locations of the phi node arguments. Patch 5 of 8 for D26256. Folding of a load operation. Differential Revision: https://reviews.llvm.org/D26256 llvm-svn: 289688
* [InstCombine] When folding GEP through a phi node merge the debug locationsRobert Lougher2016-12-141-0/+51
| | | | | | | | | | | | | If all the operands to a phi node are getelementptr, instcombine will try to pull them through the phi node, combining them into a single operation. When it does this, the debug location of the new getelementptr should be the merged debug locations of the phi node arguments. Patch 4 of 8 for D26256. Folding of a getelementptr operation. Differential Revision: https://reviews.llvm.org/D26256 llvm-svn: 289684
* [InstCombine] Merge debug locations when folding through a phi nodeRobert Lougher2016-12-141-0/+51
| | | | | | | | | | | | | If all the operands to a phi node are of the same operation, instcombine will try to pull them through the phi node, combining them into a single operation. When it does this, the debug location of the operation should be the merged debug locations of the phi node arguments. Patch 3 of 8 for D26256. Folding of a compare operation. Differential Revision: https://reviews.llvm.org/D26256 llvm-svn: 289681
* [InstCombine] Merge debug locations when folding through a phi nodeRobert Lougher2016-12-141-0/+70
| | | | | | | | | | | | | If all the operands to a phi node are of the same operation, instcombine will try to pull them through the phi node, combining them into a single operation. When it does this, the debug location of the operation should be the merged debug locations of the phi node arguments. Patch 2 of 8 for D26256. Folding of a binary operation. Differential Revision: https://reviews.llvm.org/D26256 llvm-svn: 289679
* [DWARF] Preserve column number when emitting 'line 0' recordPaul Robinson2016-12-142-3/+3
| | | | | | | | Follow-up to r289256, address a FIXME to avoid resetting the column number. This reduced .debug_line by 2.6% in a RelWithDebInfo self-build of clang. llvm-svn: 289620
* Recommit r288212: Emit 'no line' information for interesting 'orphan' ↵Paul Robinson2016-12-124-3/+80
| | | | | | | | | | | | | | | | | instructions. DWARF specifies that "line 0" really means "no appropriate source location" in the line table. By default, use this for branch targets and some other cases that have no specified source location, to prevent inheriting unfortunate line numbers from physically preceding instructions (which might be from completely unrelated source). Updated patch allows enabling or suppressing this behavior for all unspecified source locations. Differential Revision: http://reviews.llvm.org/D24180 llvm-svn: 289468
* Bigger-hammer REQUIRES to fix Windows bot.Paul Robinson2016-12-091-1/+1
| | | | llvm-svn: 289288
* Speculative REQUIRES to fix Windows bot.Paul Robinson2016-12-091-0/+1
| | | | llvm-svn: 289281
* Fix LLVM's use of DW_OP_bit_piece in DWARF expressions.Adrian Prantl2016-12-097-4/+407
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM's use of DW_OP_bit_piece is incorrect and a based on a misunderstanding of the wording in the DWARF specification. The offset argument of DW_OP_bit_piece refers to the offset into the location that is on the top of the DWARF expression stack, and not an offset into the source variable. This has since also been clarified in the DWARF specification. This patch fixes all uses of DW_OP_bit_piece to emit the correct offset and simplifies the DwarfExpression class to semi-automaticaly emit empty DW_OP_pieces to adjust the offset of the source variable, thus simplifying the code using DwarfExpression. While this is an incompatible bugfix, in practice I don't expect this to be much of a problem since LLVM's old interpretation and the correct interpretation of DW_OP_bit_piece differ only when there are gaps in the fragmented locations of the described variables or if individual fragments are smaller than a byte. LLDB at least won't interpret locations with gaps in them because is has no way to present undefined bits in a variable, and there is a high probability that an old-form expression will be malformed when interpreted correctly, because the DW_OP_bit_piece offset will be outside of the location at the top of the stack. As a nice side-effect, this patch enables us to use a more efficient encoding for subregisters: In order to express a sub-register at a non-zero offset we now use a DW_OP_bit_piece instead of shifting the value into place manually. This patch also adds missing test coverage for code paths that weren't exercised before. <rdar://problem/29335809> Differential Revision: https://reviews.llvm.org/D27550 llvm-svn: 289266
* [DWARF] Suppress .loc directives from CFI instructionsPaul Robinson2016-12-091-0/+76
| | | | | | | | | Like DBG_VALUE, these emit nothing to the .text section, and sometimes have no source location specified. Just ignore them. Differential Revision: http://reviews.llvm.org/D27492 llvm-svn: 289256
* Revert "[CodeGen] Fix invalid DWARF info on Win64"Keno Fischer2016-12-081-31/+17
| | | | | | Appears to break on build bots. Reverting pending investigation. llvm-svn: 289014
* [CodeGen] Fix invalid DWARF info on Win64Keno Fischer2016-12-081-17/+31
| | | | | | | | | | | | | | | The relocations for `DIEEntry::EmitValue` were wrong for Win64 (emitting FK_Data_4 instead of FK_SecRel_4). This corrects that oversight so that the DWARF data is correct in Win64 COFF files. Fixes PR15393. Patch by Jameson Nash <jameson@juliacomputing.com> based on a patch by David Majnemer. Differential Revision: https://reviews.llvm.org/D21731 llvm-svn: 289013
* [InlineFunction] Do not propagate the callsite debug location to ↵Andrea Di Biagio2016-12-071-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instructions inlined from functions with debug info. When a function F is inlined, InlineFunction extends the debug location of every instruction inlined from F by adding an InlinedAt. However, if an instruction has a 'null' debug location, InlineFunction would propagate the callsite debug location to it. This behavior existed since revision 210459. Revision 210459 was originally committed specifically to workaround the lack of debug information for instructions inlined from intrinsic functions (which are usually declared with attributes `__always_inline__, __nodebug__`). The problem with revision 210459 is that it doesn't make any sort of distinction between instructions inlined from a 'nodebug' function and instructions which are inlined from a function built with debug info. This issue may lead to incorrect stepping in the debugger. This patch works under the assumption that a nodebug function does not have a DISubprogram. When a function F is inlined into another function G, InlineFunction checks if F has debug info associated with it. For nodebug functions, the InlineFunction logic is unchanged (i.e. it would still propagate the callsite debugloc to the inlined instructions). Otherwise, InlineFunction no longer propagates the callsite debug location. Differential Revision: https://reviews.llvm.org/D27462 llvm-svn: 288895
* [DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operationAdrian Prantl2016-12-0520-62/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [DWARF] Put linkage-name on abstract origin even when there's a declaration.Paul Robinson2016-12-021-35/+94
| | | | | | | | | | In r266692, we made it possible to emit linkage names for just inlined functions, putting the attribute on the abstract origin. Make sure we don't think the linkage-name was already emitted on a declaration. Differential Revision: http://reviews.llvm.org/D27320 llvm-svn: 288450
* When instructions are hoisted out of loops by MachineLICM, remove their ↵Wolfgang Pieb2016-12-021-0/+141
| | | | | | | | | | | | | | | debug loc. This prevents erratic stepping behavior as well as incorrect source attribution for sample profiling. Reviewers: dblakie Subscribers: llvm-commit Differential Revision: https://reviews.llvm.org/D27290 llvm-svn: 288442
* revert r288283 as it causes debug info (line numbers) to be lost in ↵Kostya Serebryany2016-12-012-75/+1
| | | | | | instrumented code. also revert r288299 which was a workaround for the problem. llvm-svn: 288300
* Recommit r288212: Emit 'no line' information for interesting 'orphan' ↵Paul Robinson2016-11-302-1/+75
| | | | | | | | | | | | | | | | instructions. The LLDB tests are now ready for this patch. DWARF specifies that "line 0" really means "no appropriate source location" in the line table. Use this for branch targets and some other cases that have no specified source location, to prevent inheriting unfortunate line numbers from physically preceding instructions (which might be from completely unrelated source). Differential Revision: http://reviews.llvm.org/D24180 llvm-svn: 288283
* Revert r288212 due to lldb failure.Paul Robinson2016-11-292-75/+1
| | | | llvm-svn: 288216
* Emit 'no line' information for interesting 'orphan' instructions.Paul Robinson2016-11-292-1/+75
| | | | | | | | | | | | DWARF specifies that "line 0" really means "no appropriate source location" in the line table. Use this for branch targets and some other cases that have no specified source location, to prevent inheriting unfortunate line numbers from physically preceding instructions (which might be from completely unrelated source). Differential Revision: http://reviews.llvm.org/D24180 llvm-svn: 288212
* [DebugInfo] Add support for DW_AT_main_subprogram on subprogramsDavid Blaikie2016-11-281-0/+35
| | | | | | Patch by Tom Tromey! (for use with Rust) llvm-svn: 288068
* [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 the DW_AT_type for a C++ static member definitionAdrian Prantl2016-11-081-0/+71
| | | | | | | | | | | | | | | | | | | | | | if it is more specific than the one in its DW_AT_specification. If a static member is an array, the translation unit containing the member definition may have a more specific type (including its length) than TUs only seeing the class declaration. This patch adds a DW_AT_type to the member's DW_TAG_variable in addition to the DW_AT_specification in these cases. The member type in the DW_AT_specification still shows the more generic type (without the length) to avoid defeating type uniquing. The DWARF standard discourages “duplicating” a DW_AT_type in a member variable definition but doesn’t explicitly forbid it. Having the more specific type (with the array length) available is what allows the debugger to print the contents of a static array member variable. https://reviews.llvm.org/D26368 rdar://problem/28706946 llvm-svn: 286302
* Add DWARF debug info support for C++11 inline namespaces.Adrian Prantl2016-11-031-0/+40
| | | | | | | | | This implements the DWARF 5 DW_AT_export_symbols feature: http://dwarfstd.org/ShowIssue.php?issue=141212.1 <rdar://problem/18616046> llvm-svn: 285959
* 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
* Add CodeViewRecordIO for reading and writing.Zachary Turner2016-11-021-179/+99
| | | | | | | | | | | | | | | Using a pattern similar to that of YamlIO, this allows us to have a single codepath for translating codeview records to and from serialized byte streams. The current patch only hooks this up to the reading of CodeView type records. A subsequent patch will hook it up for writing of CodeView type records, and then a third patch will hook up the reading and writing of CodeView symbols. Differential Revision: https://reviews.llvm.org/D26040 llvm-svn: 285836
* Emit DW_OP_piece also if the previous value was a constant.Adrian Prantl2016-11-022-2/+120
| | | | | | This fixes a bug in the DWARF backend. llvm-svn: 285826
* DebugInfo: make DW_TAG_atomic_type validVictor Leschuk2016-10-312-0/+73
| | | | | | | | | | | | | | DW_TAG_atomic_type was already included in Dwarf.defs and emitted correctly, however Verifier didn't recognize it as valid. Thus we introduce the following changes: * Make DW_TAG_atomic_type valid tag for IR and DWARF (enabled only with -gdwarf-5) * Add it to related docs * Add DebugInfo tests Differential Revision: https://reviews.llvm.org/D26144 llvm-svn: 285624
* Do not print out Flags field twice.Rui Ueyama2016-10-281-10/+26
| | | | llvm-svn: 285481
* Reverting back r285355: "Update .debug_line section version information to ↵Ekaterina Romanova2016-10-275-45/+6
| | | | | | match DWARF version", while I'm investigating a test failure. llvm-svn: 285362
* Update .debug_line section version information to match DWARF version.Ekaterina Romanova2016-10-275-6/+45
| | | | | | | | | | In the past the compiler always emitted .debug_line version 2, though some opcodes from DWARF 3 (e.g. DW_LNS_set_prologue_end, DW_LNS_set_epilogue_begin or DW_LNS_set_isa) and from DWARF 4 could be emitted by the compiler. This patch changes version information of .debug_line to exactly match the DWARF version. For .debug_line version 4, a new field maximum_operations_per_instruction is emitted. Differential Revision: https://reviews.llvm.org/D16697 llvm-svn: 285355
* Reapply: "Remove debug location from common tail when tail-merging"Robert Lougher2016-10-262-6/+80
| | | | | | | | | | | | | | | | 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
* DebugInfo: support for DWARFv5 DW_AT_alignment attributeVictor Leschuk2016-10-264-4/+357
| | | | | | | | | | | | * Assume that clang passes non-zero alignment value to DIBuilder only in case when it was forced by C++11 'alignas', C11 '_Alignas' or compiler attribute '__attribute__((aligned (N)))'. * Emit DW_AT_alignment if alignment is specified for type/object. Differential Revision: https://reviews.llvm.org/D24425 llvm-svn: 285189
* [IndVarSimplify][DebugLoc] When widening the exit loop condition, correctly ↵Andrea Di Biagio2016-10-261-0/+8
| | | | | | | | | | | | | | | reuse the debug location of the original comparison. When the loop exit condition is canonicalized as a != compaison, reuse the debug location of the original (non canonical) comparison. Before this patch, the debug location of the new icmp was obtained from the loop latch terminator. This patch fixes the issue by correctly setting the IRBuilder's "current debug location" to the location of the original compare. Differential Revision: https://reviews.llvm.org/D25953 llvm-svn: 285185
* Revert r285181 "DebugInfo: support for DWARFv5 DW_AT_alignment attribute".Vassil Vassilev2016-10-264-357/+4
| | | | | | The commit broke the builds. llvm-svn: 285183
* DebugInfo: support for DWARFv5 DW_AT_alignment attributeVictor Leschuk2016-10-264-4/+357
| | | | | | | | | | | | * Assume that clang passes non-zero alignment value to DIBuilder only in case when it was forced by C++11 'alignas', C11 '_Alignas' or compiler attribute '__attribute__((aligned (N)))'. * Emit DW_AT_alignment if alignment is specified for type/object. Differential Revision: https://reviews.llvm.org/D24425 llvm-svn: 285181
* [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-252-80/+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-252-6/+80
| | | | | | | | | | | | | | 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
* [IndVarSimplify][Dwarf] When widening the IV increment, correctly set the ↵Andrea Di Biagio2016-10-251-0/+83
| | | | | | | | | | | | | | | debug loc. When indvars widened an induction variable, the debug location for the loop increment computation was incorrectly set equal to the debug loc of the loop latch terminator. This patch fixes the issue by propagating the correct location from the original loop increment instruction to the new widened increment. Differential Revision: https://reviews.llvm.org/D25872 llvm-svn: 285083
OpenPOWER on IntegriCloud