summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* DebugInfo: Fission: Ensure the address pool entries for location lists are ↵David Blaikie2014-06-191-1/+1
| | | | | | | | | emitted. The address pool was being emitted before location lists. The latter could add more entries to the pool which would be lost/never emitted. llvm-svn: 211284
* Emit DWARF3 call frame information when DWARF3+ debug info is requestedOliver Stannard2014-06-191-0/+2
| | | | | | | | | | | | | | | | Currently, llvm always emits a DWARF CIE with a version of 1, even when emitting DWARF 3 or 4, which both support CIE version 3. This patch makes it emit the newer CIE version when we are emitting DWARF 3 or 4. This will not reduce compatibility, as we already emit other DWARF3/4 features, and is worth doing as the DWARF3 spec removed some ambiguities in the interpretation of call frame information. It also fixes a minor bug where the "return address" field of the CIE was encoded as a ULEB128, which is only valid when the CIE version is 3. There are no test changes for this, because (as far as I can tell) none of the platforms that we test have a return address register with a DWARF register number >127. llvm-svn: 211272
* Move -dwarf-version to an MC level command line option so it'sEric Christopher2014-06-191-4/+1
| | | | | | | used by all of the MC level tools and codegen. Fix up all uses in the compiler to use this and set it on the context accordingly. llvm-svn: 211257
* PR20038: DebugInfo missing DIEs for some concrete variables.David Blaikie2014-06-151-0/+3
| | | | | | | | I haven't nailed this down entirely, but this is about as small of a test case as I can seem to construct and adequately demonstrates the crasher. I'll continue investigating the root cause/fix(es). llvm-svn: 210993
* DebugInfo: Remove some extra handling of abstract variables and instead rely ↵David Blaikie2014-06-131-25/+23
| | | | | | | | | | | | | | | solely on the delayed handling introduced in r210946 Now that we handle finding abstract variables at the end of the module, remove the upfront handling and just ensure the abstract variable is built when necessary. In theory we could have a split implementation, where inlined variables are immediately constructed referencing the abstract definition, and concrete variables are delayed - but let's go with one solution for now unless there's a reason not to. llvm-svn: 210961
* DebugInfo: Reference abstract definitions from variables in concrete ↵David Blaikie2014-06-131-1/+6
| | | | | | | | | | | | definitions that preceed their first inline definition. Rather than relying on abstract variables looked up at the time the concrete variable is created, look them up at the end of the module to ensure they're referenced even if they're created after the concrete definition. This completes/matches the work done in r209677 to handle this for the subprograms themselves. llvm-svn: 210946
* DwarfDebug::getExistingAbstractVariable: constify an existing reference ↵David Blaikie2014-06-131-1/+1
| | | | | | parameter that didn't need to be mutated. llvm-svn: 210944
* DebugInfo: Following up to r209677, refactor local variable emission to ↵David Blaikie2014-06-131-11/+30
| | | | | | | | | | | | | | | | delay the choice between emitting the definition attributes or using DW_AT_abstract_definition This doesn't fix the abstract variable handling yet, but it introduces a similar delay mechanism as was added for subprograms, causing DW_AT_location to be reordered to the beginning of the attribute list for local variables, and fixes all the test fallout for that. A subsequent commit will remove the abstract variable handling in DbgVariable and just do the abstract variable lookup at module end to ensure that abstract variables introduced after their concrete counterparts are appropriately referenced by the concrete variable. llvm-svn: 210943
* DebugInfo: Use the scope of the function declaration, if any, to name a ↵David Blaikie2014-06-061-4/+2
| | | | | | | | | | function in DWARF pubnames This ensures that member functions, for example, are entered into pubnames with their fully qualified name, rather than inside the global namespace. llvm-svn: 210379
* Fix null dereference with -debug-only=dwarfdebugAlexey Samsonov2014-06-051-2/+5
| | | | llvm-svn: 210299
* DebugInfo: Reuse existing LexicalScope to retrieve the scope's MDNode, ↵David Blaikie2014-06-051-6/+2
| | | | | | | | | rather than looking it up through the DebugLoc. No functional change intended, just streamlines the abstract variable lookup/construction to use a common entry point. llvm-svn: 210234
* DebugInfo: Roll argument insertion into variable insertion to ensure ↵David Blaikie2014-06-051-6/+5
| | | | | | | | arguments are correctly handled in all cases. No functional change intended. llvm-svn: 210233
* PR19388: DebugInfo: Emit dead arguments in their originally declared order.David Blaikie2014-06-051-5/+6
| | | | | | | | | | | | | | | | | | | | | | | Unused arguments were not being added to the argument list, but instead treated as arbitrary scope variables. This meant they weren't carefully added in the original argument order. In this particular example, though, it turns out the argument is only /mostly/ unused (well, actually it's entirely used, but in a specific way). It's a struct that, due to ABI reasons, is decomposed into chunks (exactly one chunk, since it has one member) and then passed. Since only one of those chunks is used (SROA, etc, kill the original reconstitution code) we don't have a location to describe the whole variable. In this particular case, since the struct consists of just the one int, once we have partial location information, this should have a location that describes the entire variable (since the piece is the entirety of the object). And at some point we'll need to describe the location of even /entirely/ unused arguments so that they can at least be printed on function entry. llvm-svn: 210231
* DebugInfo: Reapply r209984 (reverted in r210143), asserting that abstract ↵David Blaikie2014-06-041-9/+34
| | | | | | | | | | | | | | | | | DbgVariables have DIEs. Abstract variables within abstract scopes that are entirely optimized away in their first inlining are omitted because their scope is not present so the variable is never created. Instead, we should ensure the scope is created so the variable can be added, even if it's been optimized away in its first inlining. This fixes the incorrect debug info in missing-abstract-variable.ll (added in r210143) and passes an asserts self-hosting build, so hopefully there's not more of these issues left behind... *fingers crossed*. llvm-svn: 210221
* DebugInfo: Assert that DbgVariables have associated DIEsDavid Blaikie2014-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
* Roll DbgVariable::setMInsn into the constructor. No functional changes.Adrian Prantl2014-05-301-4/+2
| | | | llvm-svn: 209920
* Debug Info: Remove unused code. The MInsn of an _abstract_ variable isAdrian Prantl2014-05-291-2/+0
| | | | | | | never used again and updating the abstract variable for each inlined instance of it was questionable in the first place. llvm-svn: 209829
* Change representation of instruction ranges where variable is accessible.Alexey Samsonov2014-05-271-46/+32
| | | | | | | | | | | | | | Use more straightforward way to represent the set of instruction ranges where the location of a user variable is defined - vector of pairs of instructions (defining start/end of each range), instead of a flattened vector of instructions where some instructions are supposed to start the range, and the rest are supposed to "clobber" it. Simplify the code which generates actual .debug_loc entries. No functionality change. llvm-svn: 209698
* Factor out looking for prologue end into a functionAlexey Samsonov2014-05-271-12/+12
| | | | llvm-svn: 209697
* Don't pre-populate the set of keys in the map with variable locations history.Alexey Samsonov2014-05-271-11/+2
| | | | | | | | | | Current implementation of calculateDbgValueHistory already creates the keys in the expected order (user variables are listed in order of appearance), and should do so later by contract. No functionality change. llvm-svn: 209690
* DebugInfo: Simplify solution to avoid DW_AT_artificial on inlined parameters.David Blaikie2014-05-271-6/+1
| | | | | | | Originally committed in r207717, I clearly didn't look very closely at the code to understand how existing things were working... llvm-svn: 209680
* DebugInfo: Create abstract function definitions even when concrete ↵David Blaikie2014-05-271-46/+35
| | | | | | | | | | | | | | | definitions preceed inline definitions. After much puppetry, here's the major piece of the work to ensure that even when a concrete definition preceeds all inline definitions, an abstract definition is still created and referenced from both concrete and inline definitions. Variables are still broken in this case (see comment in dbg-value-inlined-parameter.ll test case) and will be addressed in follow up work. llvm-svn: 209677
* DebugInfo: Avoid an extra map lookup when finding abstract subprogram DIEs.David Blaikie2014-05-271-1/+1
| | | | llvm-svn: 209676
* DebugInfo: Lazily construct subprogram definition DIEs.David Blaikie2014-05-271-10/+22
| | | | | | | | | | | | | | | | A further step to correctly emitting concrete out of line definitions preceeding inlined instances of the same program. To do this, emission of subprograms must be delayed until required since we don't know which (abstract only (if there's no out of line definition), concrete only (if there are no inlined instances), or both) DIEs are required at the start of the module. To reduce the test churn in the following commit that actually fixes the bug, this commit introduces the lazy DIE construction and cleans up test cases that are impacted by the changes in the resulting DIE ordering. llvm-svn: 209675
* DebugInfo: Lazily attach definition attributes to definitions.David Blaikie2014-05-271-0/+21
| | | | | | | | | | | | | | | | | | | | | This is a precursor to fixing inlined debug info where the concrete, out-of-line definition may preceed any inlined usage. To cope with this, the attributes that may appear on the concrete definition or the abstract definition are delayed until the end of the module. Then, if an abstract definition was created, it is referenced (and no other attributes are added to the out-of-line definition), otherwise the attributes are added directly to the out-of-line definition. In a couple of cases this causes not just reordering of attributes, but reordering of types. When the creation of the attribute is delayed, if that creation would create a type (such as for a DW_AT_type attribute) then other top level DIEs may've been constructed during the delay, causing the referenced type to be created and added after those intervening DIEs. In the extreme case, in cross-cu-inlining.ll, this actually causes the DW_TAG_basic_type for "int" to move from one CU to another. llvm-svn: 209674
* DebugInfo: Put concrete definitions referencing abstract definitions in the ↵David Blaikie2014-05-231-1/+3
| | | | | | | | | | | | | | | | | | | same scope as the abstract definition. This seems like a simple cleanup/improved consistency, but also helps lay the foundation to fix the bug mentioned in the test case: concrete definitions preceeding any inlined usage aren't properly split into concrete + abstract (because they're not known to need it until it's too late). Once we start deferring this choice until later, we won't have the choice to put concrete definitions for inlined subroutines in a different scope from concrete definitions for non-inlined subroutines (since we won't know at time-of-construction which one it'll be). This change brings those two cases into alignment ahead of that future chaneg/fix. llvm-svn: 209547
* Add FIXME comment based on code review feedback by Hal Finkel on r209338David Blaikie2014-05-231-0/+2
| | | | llvm-svn: 209529
* Rename a couple of variables to be more accurate.David Blaikie2014-05-231-8/+8
| | | | | | | | It's not really a "ScopeDIE", as such - it's the abstract function definition's DIE. And we usually use "SP" for subprograms, rather than "Sub". llvm-svn: 209499
* DebugInfo: Fix cross-CU references for scopes (and variables within those ↵David Blaikie2014-05-231-3/+4
| | | | | | | | scopes) in abstract definitions of cross-CU inlined functions Found by Adrian Prantl during post-commit review of r209335. llvm-svn: 209498
* DebugInfo: Simplify dead variable collection slightly.David Blaikie2014-05-221-3/+1
| | | | | | | | constructSubprogramDIE was already called for every subprogram in every CU when the module was started - there's no need to call it again at module finalization. llvm-svn: 209372
* Revert "DebugInfo: Don't put fission type units in comdat sections."David Blaikie2014-05-211-14/+10
| | | | | | | | | This reverts commit r208930, r208933, and r208975. It seems not all fission consumers are ready to handle this behavior. Reverting until tools are brought up to spec. llvm-svn: 209338
* DebugInfo: Use the SPMap to find the parent CU of inlined functions as they ↵David Blaikie2014-05-211-13/+11
| | | | | | | | | | | | | | | | may not be in the current CU Committed in r209178 then reverted in r209251 due to LTO breakage, here's a proper fix for the case of the missing subprogram DIE. The DIEs were there, just in other compile units. Using the SPMap we can find the right compile unit to search for and produce cross-unit references to describe this kind of inlining. One existing test case needed to be updated because it had a function that wasn't in the CU's subprogram list, so it didn't appear in the SPMap. llvm-svn: 209335
* DebugInfo: Ensure concrete out of line variables from inlined functions ↵David Blaikie2014-05-211-20/+25
| | | | | | reference their abstract origins. llvm-svn: 209327
* Revert "DebugInfo: Assume all subprogram DIEs have been created before any ↵David Blaikie2014-05-201-5/+5
| | | | | | | | | | | | | | abstract subprograms are constructed." This reverts commit r209178. This seems to be asserting in an LTO build on some internal Apple buildbots. No upstream reproduction (and I don't have an LLVM-aware gold built right now to reproduce it personally) but it's a small patch & the failure's semi-plausible so I'm going to revert first while I try to reproduce this. llvm-svn: 209251
* Rewrite calculateDbgValueHistory to make it (hopefully) more transparent.Alexey Samsonov2014-05-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | This change preserves the original algorithm of generating history for user variables, but makes it more clear. High-level description of algorithm: Scan all the machine basic blocks and machine instructions in the order they are emitted to the object file. Do the following: 1) If we see a DBG_VALUE instruction, add it to the history of the corresponding user variable. Keep track of all user variables, whose locations are described by a register. 2) If we see a regular instruction, look at all the registers it clobbers, and terminate the location range for all variables described by these registers. 3) At the end of the basic block, terminate location ranges for all user variables described by some register. Although this change shouldn't be user-visible (the contents of .debug_loc section should be the same), it changes some internal assumptions about the set of instructions used to track the variable locations. Watching the bots. llvm-svn: 209225
* DebugInfo: Emit function definitions within their namespace scope.David Blaikie2014-05-201-22/+0
| | | | | | | | This workaround (presumably for ancient GDB) doesn't appear to be required (GDB 7.5 seems to tolerate function definition DIEs in namespace scope just fine). llvm-svn: 209189
* DebugInfo: Assume all subprogram DIEs have been created before any abstract ↵David Blaikie2014-05-191-5/+5
| | | | | | | | | | | | | | subprograms are constructed. Since we visit the whole list of subprograms for each CU at module start, this is clearly true - don't test for the case, just assert it. A few old test cases seemed to have incomplete subprogram lists, but any attempt to reproduce them shows full subprogram lists that even include entities that have been completely inlined and the out of line definition removed. llvm-svn: 209178
* DebugInfo: Don't include DW_AT_inline on each abstract definition multiple ↵David Blaikie2014-05-191-1/+0
| | | | | | | | | | | | | | | | | times. When I refactored this in r208636 I accidentally caused this to be added multiple times to each abstract subprogram (not accounting for the deduplicating effect of the InlinedSubprogramDIEs set). This got better in r208798 when the abstract definitions got the attribute added to them at construction time, but still had the redundant copies introduced in r208636. This commit removes those excess DW_AT_inlines and relies solely on the insertion in r208798. llvm-svn: 209166
* DebugInfo: Fix missing inlined_subroutines caused by r208748.David Blaikie2014-05-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The check in DwarfDebug::constructScopeDIE was meant to consider inlined subroutines as any non-top-level scope that was a subprogram. Instead of checking "not top level scope" it was checking if the /subprogram's/ scope was non-top-level. Fix this and beef up a test case to demonstrate some of the missing inlined_subroutines are no longer missing. In the course of fixing this I also found that r208748 (with this fix) found one /extra/ inlined_subroutine in concrete_out_of_line.ll due to two inlined_subroutines having the same inlinedAt location. The previous implementation was collapsing these into a single inlined subroutine. I'm not sure what the original code was that created this .ll file so I'm not sure if this actually happens in practice today. Since we deliberately include column information to disambiguate two calls on the same line, that may've addressed this bug in the frontend, but it's good to know that workaround isn't necessary for this particular case anymore. llvm-svn: 209165
* DebugInfo: Assert rather than conditionalizing when a CU's subprogram list ↵David Blaikie2014-05-161-2/+2
| | | | | | contains declarations. llvm-svn: 209039
* DebugInfo: Add an assert regarding the subprogram in the subprogram map ↵David Blaikie2014-05-161-0/+1
| | | | | | | | | | matching the abstract subprogram. I'm not sure this is how it'll be going forward (I'd rather prefer the definition to be in the main SP mapping, for various reasons) but this helps me understand how it is today. llvm-svn: 209009
* DebugInfo: Assume the CU's Subprogram list only contains definitions.David Blaikie2014-05-161-4/+1
| | | | | | | | | | | DIBuilder maintains this invariant and the current DwarfDebug code could end up doing weird things if it contained declarations (such as putting the definition DIE inside a CU that contained the declaration - this doesn't seem like a good idea, so rather than adding logic to handle this case we'll just ban in for now & cross that bridge if we come to it later). llvm-svn: 209004
* DwarfDebug: Refactor AT_ranges/AT_high_pc+AT_low_pc emission into helper ↵David Blaikie2014-05-161-39/+17
| | | | | | function. llvm-svn: 208997
* DebugInfo: Don't put fission type units in comdat sections.David Blaikie2014-05-151-10/+14
| | | | | | | | | Since type units in the dwo file are handled by a debug aware tool, they don't need to leverage the ELF comdat grouping to implement deduplication. Avoid creating all the .group sections for these as a space optimization. llvm-svn: 208930
* DebugInfo: Simplify retrieving filename/directory name for line table entry ↵David Blaikie2014-05-151-26/+6
| | | | | | building. llvm-svn: 208911
* DwarfDebug: Don't set frame index locations on abstract variables.David Blaikie2014-05-141-2/+0
| | | | | | | | Abstract variables should never have/use locations. In this case the data wasn't used, so no functional change intended here, just simplification. llvm-svn: 208820
* DebugInfo: Sure up subprogram variable list handling with more assertions ↵David Blaikie2014-05-141-33/+31
| | | | | | | | | | | | and fewer conditionals. Many old tests using prior schemas still had some brokenness here (both indirect arrays and arrays with single bogus elements). Fixed those up so they don't hit the new assertions. Also reduced nesting in some places, etc. llvm-svn: 208817
* DebugInfo: Assert that a CU's subprogram list contains only subprograms.David Blaikie2014-05-141-2/+2
| | | | llvm-svn: 208816
* DebugInfo: Do not delay attaching DW_AT_inline attribute to abstract ↵David Blaikie2014-05-141-15/+5
| | | | | | | | | | definitions. This is just unneccessary - we only create abstract definitions when we're inlining anyway, so there's no reason to delay this to see if we're going to inline anything. llvm-svn: 208798
* Recommit r208506: DebugInfo: Include lexical scopes in inlined subroutines.David Blaikie2014-05-141-5/+7
| | | | | | | | | | | | | | | | | | | | This was reverted in r208642 due to regressions surrounding file changes within lexical scopes causing inlining information to be lost. The issue was in LexicalScopes::getOrCreateInlinedScope, where I was previously testing "isLexicalBlock" which is false for "DILexicalBlockFile" (a scope used to represent changes in the current file name) and assuming it was then a function (breaking out of the inlined scope path and reaching for the parent non-inlined scopes). By inverting the condition and testing for "isSubprogram" the correct behavior is attained. (also found some weirdness in Clang, see r208742 when reducing this test case - the resulting test case doesn't apply with the Clang fix, but I've added a more realistic test case to inline-scopes.ll which does reproduce the issue and demonstrate the fix) llvm-svn: 208748
OpenPOWER on IntegriCloud