summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[DWARF] Incorrect prologue end line record."Robert Lougher2017-09-121-3/+1
| | | | | | | This reverts commit r313047 as it is causing buildbot failure (lldb inline stepping tests). llvm-svn: 313057
* [DWARF] Incorrect prologue end line record.Robert Lougher2017-09-121-1/+3
| | | | | | | | | | | | A prologue-end line record is emitted with an incorrect associated address, which causes a debugger to show the beginning of function body to be inside the prologue. Patch written by Carlos Alberto Enciso. Differential Revision: https://reviews.llvm.org/D37625 llvm-svn: 313047
* [DWARF] Line 0 should not have a discriminator.Paul Robinson2017-09-071-2/+2
| | | | | | | | It's meaningless and takes up extra space in the line table. Differential Revision: https://reviews.llvm.org/D37364 llvm-svn: 312751
* Untabify.NAKAMURA Takumi2017-08-281-5/+5
| | | | llvm-svn: 311875
* Filter out non-constant DIGlobalVariableExpressions reachable via the CUAdrian Prantl2017-08-191-2/+9
| | | | | | | | | They won't affect the DWARF output, but they will mess with the sorting of the fragments. This fixes the crash reported in PR34159. https://bugs.llvm.org/show_bug.cgi?id=34159 llvm-svn: 311217
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-08-171-29/+51
| | | | | | other minor fixes (NFC). llvm-svn: 311124
* Assert that the offset of a DBG_VALUE is always 0. (NFC)Adrian Prantl2017-08-021-2/+4
| | | | llvm-svn: 309834
* Remove the unused Offset field from MachineLocation (NFC)Adrian Prantl2017-08-021-5/+1
| | | | | | rdar://problem/33580047 llvm-svn: 309831
* Remove unreachable code. (NFC)Adrian Prantl2017-08-021-7/+1
| | | | | | | | MachineLocation::getOffset() always returns 0. rdar://problem/33580047 llvm-svn: 309823
* DebugInfo: Update flag description that'd been copypasted from anotherDavid Blaikie2017-08-011-1/+1
| | | | | | Post-commit review feedback from Paul Robinson on r309630. Thanks Paul! llvm-svn: 309685
* DebugInfo: Put range base specifier entry functionality behind a flagDavid Blaikie2017-07-311-4/+9
| | | | | | | | Chromium's gold build seems to have trouble with this (gold produces errors) - not sure if it's gold that's not coping with the valid representation, or a bug in the implementation in LLVM, etc. llvm-svn: 309630
* DebugInfo: Fix r309526, ensure resetting base address selection entries are usedDavid Blaikie2017-07-311-0/+6
| | | | | | | Missed the resetting base address selections when going from a base address version to zero base address for non-base-addressed entries. llvm-svn: 309529
* DebugInfo: Use base address selection entries in debug_ranges to reduce ↵David Blaikie2017-07-301-10/+35
| | | | | | | | | | | | | | | | | | | | relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
* DebugInfo: Consider a CU containing only local imported entities to be 'empty'David Blaikie2017-07-281-11/+14
| | | | | | | | | | | | | | | | | | | | | | | This can come up in ThinLTO & wastes space & makes degenerate IR. As per the added FIXME, ultimately, local imported entities should hang off the function and that way the imported entity list on the CU can be tested for emptiness like all the other CU lists. (function-attached local imported entities are probably also the best path forward for fixing how imported entities are handled both in cross-module use (currently, while ThinLTO preserves the imported entities, they would not get used at the imported inlined location - only in the abstract origin that appears in the partial CU created by the import (which isn't emitted under Fission due to cross-CU limitations there)) and to reduce the number of points where imported entities are emitted (they're currently emitted into every inlined instance, concrete instance, and abstract origin - they should only go in teh abstract origin if there is one, otherwise in the concrete instance - but this requires lots of delayed handling and wiring up, same as abstract variables & subprograms)) llvm-svn: 309354
* remove redundant checkAdrian Prantl2017-07-271-1/+1
| | | | llvm-svn: 309280
* DebugInfo: Ensure imported entities at the top level of an inlined function ↵David Blaikie2017-07-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | don't cause degenerate concrete definitions Local imported entities at the top level of a subprogram were being handled differently from those in nested scopes - that different handling would cause pseudo concrete out-of-line definitions to be created (but without any of their attributes, nor an abstract_origin) in the case where there was no real concrete definition. These local imported entities also only appeared in the concrete definition where those imported entities in nested scopes appear in all cases (abstract, concrete, and inlined). This change at least makes top level case handle the same as the others - though there's a FIXME to improve this to /only/ emit them into the abstract origin (though this requires more plumbing - like the abstract subprogram and variable handling that must defer population until the end of the unit to discover if there is an abstract origin, or only a standalone concrete definition). llvm-svn: 309237
* Do a better job at emitting prefrabricated skeleton CUs.Adrian Prantl2017-07-261-4/+14
| | | | | | | | | | | | | | | | | | | | This is a better fix than r308708 for the problem introduced in r304020. It restores the skeleton CU testcases modified by that commit to their original form and most importantly ensures that frontend-generated skeleton CUs (such as used to point to Clang modules) come after the regular CUs. This broke for DICompileUnit nodes that don't have any immediate children because they are now constructed lazily instead of the order in which they are listed in !llvm.dbg.cu. After this commit we still don't guarantee that order, but we do guarantee that empty skeletons come last. Shipping versions of LLDB are very sensitive to the ordering of CUs. I'll track a fix for LLDB to be more permissive separately. This fixes a test failure in the LLDB testsuite. rdar://problem/33357252 llvm-svn: 309154
* Debug Info: Support fragmented variables in the MMI side tableAdrian Prantl2017-07-251-1/+6
| | | | | | This reapplies commit r309034 with a bugfix+test for inlined variables. llvm-svn: 309057
* Revert "Debug Info: Support fragmented variables in the MMI side table"Adrian Prantl2017-07-251-6/+1
| | | | | | This reverts commit r309034 because of a sanitizer issue. llvm-svn: 309035
* Debug Info: Support fragmented variables in the MMI side tableAdrian Prantl2017-07-251-1/+6
| | | | | | <rdar://problem/17816343> llvm-svn: 309034
* Debug Info: Don't strip clang module skeleton CUs.Adrian Prantl2017-07-211-1/+2
| | | | | | | | This corrects a (hopefully :-) accidental side-effect of r304020. rdar://problem/33442618 llvm-svn: 308708
* Fix a crash in DwarfDebug::validThroughout.Adrian Prantl2017-06-201-3/+5
| | | | | | | | | | | The instruction it falls over on is an IMPLICT_DEF that also happens to be the only instruction in its lexical scope. That LexicalScope has never been created because its range is empty. This patch skips over all meta-instructions instead of just DBG_VALUEs. Thanks to David Blaikie for providing a testcase! llvm-svn: 305853
* Improve the accuracy of variable ranges .debug_loc location lists.Adrian Prantl2017-06-161-12/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the following motivating example bool c(); void f(); bool start() { bool result = c(); if (!c()) { result = false; goto exit; } f(); result = true; exit: return result; } we would previously generate a single DW_AT_const_value(1) because only the DBG_VALUE in the second-to-last basic block survived codegen. This patch improves the heuristic used to determine when a DBG_VALUE is available at the beginning of its variable's enclosing lexical scope: - Stop giving singular constants blanket permission to take over the entire scope. There is still a special case for constants in the function prologue that we also miight want to retire later. - Use the lexical scope information to determine available-at-entry instead of proximity to the function prologue. After this patch we generate a location list with a more accurate narrower availability for the constant true value. As a pleasant side effect, we also generate inline locations instead of location lists where a loacation covers the entire range of the enclosing lexical scope. Measured on compiling llc with four targets this doesn't have an effect on compile time and reduces the size of the debug info for llc by ~600K. rdar://problem/30286912 llvm-svn: 305599
* Align definition of DW_OP_plus with DWARF spec [3/3]Florian Hahn2017-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things. The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack. This is done in three stages: • The first patch (LLVM) adds support for DW_OP_plus_uconst. • The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst. • The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions. Patch by Sander de Smalen. Reviewers: echristo, pcc, aprantl Reviewed By: aprantl Subscribers: fhahn, javed.absar, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D33894 llvm-svn: 305386
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* DebugInfo: Include .dwo file name when hashing multiple CUs in a single fileMehdi Amini2017-05-291-1/+9
| | | | | | | | | | | | | | | | | | | | | | | This is really a workaround for ThinLTO in particular - since it can import partial CUs that may end up looking very similar/the same as the same partial import in another ThinLTO compile. An alternative fix would be to change the DICompileUnit metadata to include a "primary file" or the like - and when importing for ThinLTO set the primary file to the name of the DICompileUnit that is being imported into. This involves changing the schema and would reduce the excessive uniqueness in the hash that this change creates - allowing diagnosing of more duplicate CUs than will be caught with this change. But duplicate CUs can still be caught in non-ThinLTO builds & are mostly a nuisance rather than a particularly deliberate/effective tool for finding broken code. (arguably the hash could always include the dwo file and nothing in fission would break, I think..) Reapply of r304119 after adding a triple to the test and moving it to the X86 directory. llvm-svn: 304130
* DebugInfo: Omit an empty CU when a subprogram was moved into its useMehdi Amini2017-05-291-8/+12
| | | | | | | | | | | When the only use of a CU is for a subprogram that's only emitted into the using CU (to avoid cross-CU references in DWO files), avoid creating that CU at all. Reapply of r304111 after adding a triple to the test and moving it to the X86 directory. llvm-svn: 304129
* Revert "DebugInfo: Omit an empty CU when a subprogram was moved into its use"Mehdi Amini2017-05-291-12/+8
| | | | | | | This reverts commit r304111. GreenDragon is broken. llvm-svn: 304126
* Revert "DebugInfo: Include .dwo file name when hashing multiple CUs in a ↵Mehdi Amini2017-05-291-9/+1
| | | | | | | | single file" This reverts commit r304119 and r304118. GreenDragon is broken. llvm-svn: 304125
* DebugInfo: Include .dwo file name when hashing multiple CUs in a single fileDavid Blaikie2017-05-291-1/+9
| | | | | | | | | | | | | | | | | | | | This is really a workaround for ThinLTO in particular - since it can import partial CUs that may end up looking very similar/the same as the same partial import in another ThinLTO compile. An alternative fix would be to change the DICompileUnit metadata to include a "primary file" or the like - and when importing for ThinLTO set the primary file to the name of the DICompileUnit that is being imported into. This involves changing the schema and would reduce the excessive uniqueness in the hash that this change creates - allowing diagnosing of more duplicate CUs than will be caught with this change. But duplicate CUs can still be caught in non-ThinLTO builds & are mostly a nuisance rather than a particularly deliberate/effective tool for finding broken code. (arguably the hash could always include the dwo file and nothing in fission would break, I think..) llvm-svn: 304119
* DebugInfo: Omit an empty CU when a subprogram was moved into its useDavid Blaikie2017-05-281-8/+12
| | | | | | | | When the only use of a CU is for a subprogram that's only emitted into the using CU (to avoid cross-CU references in DWO files), avoid creating that CU at all. llvm-svn: 304111
* DebugInfo: Do not emit empty CUsDavid Blaikie2017-05-261-14/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consistent with GCC and addresses a shortcoming with ThinLTO where many imported CUs may end up being empty (because the functions imported from them either ended up not being used (and were then discarded, since they're imported as available_externally) or optimized away entirely). Test cases previously testing empty CUs (either intentionally, or because they didn't need anything more complicated) had a trivial 'int' or similar basic type added to their retained types list. This is a first order approximation - a deeper implementation could do things like: 1) Be more lazy about construction of the CU - for example if two CUs containing a single identical retained type are linked together, with this change one of the two CUs will be produced but empty (since a duplicate type won't be produced). 2) Go further and invert all the CU links the same way the subprogram link is inverted - keep named CU lists of retained types, macros, etc, and have those link back to the CU. Then if they're emitted, the CU is emitted, but never otherwise - this would allow the metadata itself to be dropped earlier too, though it seems unlikely that's an important optimization as there shouldn't be many CUs relative to the number of other entities. llvm-svn: 304020
* DebugInfo: Don't include locations for debug-having code inlined into ↵David Blaikie2017-05-261-0/+4
| | | | | | | | | | | | | | | nodebug functions This produced 'strange' DWARF anyway - the CU would have no ranges (or at least not a range including the inlined code) nor any subprogram or inlined_subroutine - yet the line table would have entries for these instructions. (this actually becomes more relevant with changes coming after this, where a CU without any contents will be omitted entirely - so there would be no line table to put this on anyway) llvm-svn: 304004
* DebugInfo: Simplify scopes+subprogram handling since the subprogram<>cu link ↵David Blaikie2017-05-251-18/+8
| | | | | | | | | | | | inversion Previously this code was defensive to the situation in which the debug info scopes would lead to a different subprogram from the subprogram in the CU's subprogram list (this could've happened with linkonce functions, etc as per the comment being removed). Since the CU<>SP link reversal this is no longer possible. llvm-svn: 303933
* DebugInfo: Produce debug_{gnu_}pub{names,types} entries when explicitly ↵David Blaikie2017-05-251-10/+18
| | | | | | | | | | | | | | | | | requested, even in -gmlt or when empty Turns out gold doesn't use the DW_AT_GNU_pubnames to decide whether to parse the rest of the DIEs when building gdb-index. This causes gold to trip over LLVM's output when there are DW_FORM_ref_addr present. Gold does use the presence of a debug_gnu_pub{names,types} entry for the CU to skip parsing the debug_info portion, so make sure that's included even when empty (technically, when empty there couldn't be any ref_addr anyway - it only came up when gmlt didn't produce any (even non-empty) pubnames - but given what that reveals about gold's implementation, this seems like a good thing to do for consistency). llvm-svn: 303894
* Don't generate line&scope debug info for meta-instructions.Adrian Prantl2017-05-221-2/+2
| | | | | | | | | | | | | | | MachineInstructions that don't generate any code (such as IMPLICIT_DEFs) should not generate any debug info either. Fixes PR33107. https://bugs.llvm.org/show_bug.cgi?id=33107 This reapplies r303566 without any modifications. The stage2 build failures persisted even after reverting this patch, and looking back through history, it looks like these tests are flaky. llvm-svn: 303575
* Revert "Don't generate line&scope debug info for meta-instructions."Adrian Prantl2017-05-221-2/+2
| | | | | | This reverts commit r303566 while investigating a stage2 buildbot failure. llvm-svn: 303570
* Don't generate line&scope debug info for meta-instructions.Adrian Prantl2017-05-221-2/+2
| | | | | | | | | | | MachineInstructions that don't generate any code (such as IMPLICIT_DEFs) should not generate any debug info either. Fixes PR33107. https://bugs.llvm.org/show_bug.cgi?id=33107 llvm-svn: 303566
* DWARF: Avoid cross-CU references under FissionDavid Blaikie2017-05-121-54/+35
| | | | | | | | | | | | | | | | | | Turns out that the Fission/Split DWARF package format (DWP) is currently insufficient to handle cross-CU (ref_addr) references. So for now, duplicate any debug info needed in these situations: * inlined_subroutine's abstract_origin * inlined variable's abstract_origin * types Keep the ref_addr behavior in general, including in the split DWARF inline debug info that can be emitted into the object files for online symbolication. Keep a flag to use the old (ref_addr) behavior for testing ways of addressing this limitation in the DWP tool (& for those not using DWP packaging). llvm-svn: 302858
* Move Split DWARF handling to an MC option/command line argument rather than ↵David Blaikie2017-04-211-15/+4
| | | | | | | | | | | | | | | | | | | using metadata Since Split DWARF needs to name the actual .dwo file that is generated, it can't be known at the time the llvm::Module is produced as it may be merged with other Modules before the object is generated and that object may be generated with any name. By passing the Split DWARF file name when LLVM is producing object code the .dwo file name in the object file can match correctly. The support for Split DWARF for implicit modules remains the same - using metadata to store the dwo name and dwo id so that potentially multiple skeleton CUs referring to different dwo files can be generated from one llvm::Module. llvm-svn: 301062
* Fix bug that caused DwarfExpression to drop DW_OP_deref from FI locationsAdrian Prantl2017-04-191-1/+3
| | | | | | | | | | | - introduced in r300522 and found via the Swift LLDB testsuite. The fix is to set the location kind to memory whenever an FrameIndex location is emitted. rdar://problem/31707602 llvm-svn: 300793
* Revert "Fix bug that caused DwarfExpression to drop DW_OP_deref from FI ↵Adrian Prantl2017-04-191-3/+1
| | | | | | | | locations" This reverts commit r300790. llvm-svn: 300792
* Fix bug that caused DwarfExpression to drop DW_OP_deref from FI locationsAdrian Prantl2017-04-191-1/+3
| | | | | | | | | | | - introduced in r300522 and found via the Swift LLDB testsuite. The fix is to set the location kind to memory whenever an FrameIndex location is emitted. rdar://problem/31707602 llvm-svn: 300790
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-181-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* Distinguish between code pointer size and DataLayout::getPointerSize() in ↵Konstantin Zhuravlyov2017-04-171-3/+3
| | | | | | DWARF info generation llvm-svn: 300463
* If the DIUnit has flags passed on it then have DW_AT_producer be a ↵Eric Christopher2017-03-291-1/+8
| | | | | | | | | | combination of DICompileUnit::Producer and Flags. The darwin behavior is unchanged and will continue to use DW_AT_APPLE_flags. Patch by Zhizhou Yang llvm-svn: 299038
* Fix PR32298 by adding an early exit to getFrameIndexExprs().Adrian Prantl2017-03-221-0/+6
| | | | | | | | Also add an assertion for the case that there are multiple FI expressions with a DW_OP_LLVM_fragment; which should violate internal constraints in DbgVariable. llvm-svn: 298518
* Add a function to MD5 a file's contents.Zachary Turner2017-03-201-4/+3
| | | | | | | | | | | | | | | In doing so, clean up the MD5 interface a little. Most existing users only care about the lower 8 bytes of an MD5, but for some users that care about the upper and lower, there wasn't a good interface. Furthermore, consumers of the MD5 checksum were required to handle endianness details on their own, so it seems reasonable to abstract this into a nicer interface that just gives you the right value. Differential Revision: https://reviews.llvm.org/D31105 llvm-svn: 298322
* Replace uses of DwarfExpression::addMachineReg* with addMachineRegExpressionAdrian Prantl2017-03-201-7/+17
| | | | | | | | | | | | | and mark the methods as protected. Besides reducing the surface area of DwarfExpression, this is in preparation for an upcoming bugfix in the DwarfExpression implementation, for which it will be necessary to defer emitting register operations until the rest of the expression is known. NFC llvm-svn: 298309
* Rename methods in DwarfExpression to adhere to the LLVM coding guidelines.Adrian Prantl2017-03-161-9/+9
| | | | | | NFC. llvm-svn: 297966
OpenPOWER on IntegriCloud