summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [NFC] Rename DwarfAccelTable and move header.Jonas Devlieghere2018-01-291-1/+1
| | | | | | | | | | This patch renames DwarfAccelTable.{h,cpp} to AccelTable.{h,cpp} and moves the header to the include dir so it is accessible by the dsymutil implementation. Differential revision: https://reviews.llvm.org/D42529 llvm-svn: 323654
* [NFC] Refactor Apple Accelerator TablesJonas Devlieghere2018-01-291-20/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
* [DWARF] Generate DWARF v5 string offsets tables along with strx* index forms.Wolfgang Pieb2018-01-261-2/+47
| | | | | | | | | | | | Summary: This is the producer side for DWARF v5 string offsets tables. The reader/consumer side was committed with r321295. All compile and type units in a module share a contribution to the string offsets table. Indirect strings use the strx{1,2,3,4} index forms. Reviewers: dblaikie, aprantl, JDevliegehere Differential Revision: https://reviews.llvm.org/D42021 llvm-svn: 323546
* Don't emit apple accelerator tables on non-darwin targetsPavel Labath2018-01-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently -glldb turns on emission of apple tables on all targets, but lldb is only really capable of consuming them on darwin. Furthermore, making lldb consume these tables is not straight-forward because of the differences in how the debug info is distributed on darwin vs. elf targets. The darwin debug model assumes that the debug info (along with accelerator tables) will either remain in the .o files or it will be linked into a dsym bundle by a linker that knows how to merge these tables. In the elf world, all present linkers will simply concatenate these accelerator tables into the shared object. Since the tables are not self-terminating, this renders the tables unusable, as the debugger cannot pry the individual tables apart anymore. It might theoretically be possible to make the tables work with split dwarf, as that is somewhat similar to the apple .o model, but unfortunately right now the combination of -glldb and -gsplit-dwarf produces broken object files. Until these issues are resolved there is no point in emitting the apple tables for these targets. At best, it wastes space; at worst, it breaks compilation and prevents the user from getting other benefits of -glldb. Reviewers: probinson, aprantl, dblaikie Subscribers: emaste, dim, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41986 llvm-svn: 322633
* [DWARFv5] CodeGen support for MD5 file checksumsPaul Robinson2018-01-121-8/+2
| | | | | | | | | | Pass MD5 checksums through from IR to assembly/object files. After this, getting Clang to compute the MD5 should be the last step to supporting MD5 in the DWARF v5 line table header. Differential Revision: https://reviews.llvm.org/D41926 llvm-svn: 322391
* [DWARFv5] MC support for MD5 file checksumsPaul Robinson2018-01-091-2/+3
| | | | | | | Extend .file directive syntax to allow specifying an MD5 checksum for the source file. Emit the checksums in DWARF v5 line tables. llvm-svn: 322134
* MachineFunction: Return reference from getFunction(); NFCMatthias Braun2017-12-151-3/+3
| | | | | | The Function can never be nullptr so we can return a reference. llvm-svn: 320884
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-3/+3
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* [DWARF] Fix bad comparator in sortGlobalExprs.Eli Friedman2017-10-121-7/+12
| | | | | | | | | | | | | | | | | | The comparator passed to std::sort must provide a strict weak ordering; otherwise, the behavior is undefined. Fixes an assertion failure generating debug info for globals split by GlobalOpt. I have a testcase, but not sure how to reduce it, so not included here. (Someone else came up with a testcase, but I can't reproduce the crash with it, presumably because my version of LLVM ends up sorting the array differently.) This isn't really a complete fix (see the FIXME in the patch), but at least it doesn't have undefined behavior. Differential Revision: https://reviews.llvm.org/D38830 llvm-svn: 315619
* Reinstantiate old/bad deduplication logic that was removed in r315279.Daniel Jasper2017-10-121-0/+10
| | | | | | | | | | | While this shouldn't be necessary anymore, we have cases where we run into the assertion below, i.e. cases with two non-fragment entries for the same variable at different frame indices. This should be fixed, but for now, we should revert to a version that does not trigger asserts. llvm-svn: 315576
* CodeGen: Minor cleanups to use MachineInstr::getMF. NFCJustin Bogner2017-10-101-1/+1
| | | | | | | Since r315388 we have a shorter way to say this, so we'll replace MI->getParent()->getParent() with MI->getMF() in a few places. llvm-svn: 315390
* Ignore all duplicate frame index expressionBjorn Steinbrink2017-10-101-0/+25
| | | | | | | | | | | | | | | | | Some passes might duplicate calls to llvm.dbg.declare creating duplicate frame index expression which currently trigger an assertion which is meant to catch erroneous, overlapping fragment declarations. But identical frame index expressions are just redundant and don't actually conflict with each other, so we can be more lenient and just ignore the duplicates. Reviewers: aprantl, rnk Subscribers: llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D38540 llvm-svn: 315279
* IR: Represent -ggnu-pubnames with a flag on the DICompileUnit.Peter Collingbourne2017-09-121-91/+52
| | | | | | | | This allows the flag to be persisted through to LTO. Differential Revision: https://reviews.llvm.org/D37655 llvm-svn: 313078
* 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
OpenPOWER on IntegriCloud