summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
* Fix line numbers for code inlined from __nodebug__ functions.Evgeniy Stepanov2014-06-091-0/+69
| | | | | | | | | | | | | | Instructions from __nodebug__ functions don't have file:line information even when inlined into no-nodebug functions. As a result, intrinsics (SSE and other) from <*intrin.h> clang headers _never_ have file:line information. With this change, an instruction without !dbg metadata gets one from the call instruction when inlined. Fixes PR19001. llvm-svn: 210459
* Fix typosAlp Toker2014-06-071-1/+1
| | | | llvm-svn: 210401
* DebugInfo: Use the scope of the function declaration, if any, to name a ↵David Blaikie2014-06-062-8/+4
| | | | | | | | | | 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
* DebugInfo: pubnames: include file-local (static or anonymous namespace) ↵David Blaikie2014-06-064-66/+190
| | | | | | | | | variables and anonymous namespaces themselves. Still some issues with name qualification, FIXMEs added to test cases and fixes will come next. llvm-svn: 210378
* Match the full hex offsets in test/DebugInfo/X86/gnu-public-names.llDavid Blaikie2014-06-061-24/+24
| | | | | | | | | | | | | | | | | These checks were accidentally skipping the 0x prefix in the hex offsets, then cunningly ignoring the prefix in the use of those captured values. Except in the case of the unit length, where the match was only matching the leading '0' before the x in the 0x prefix, then matching that against the length. We can't actually express the length association here, as the length field in the Compile Unit header does not include the length field itself, but the length field in the pubnames section /does/ include the size of the length field in the Compile Unit header - so the two numbers are actually 4 bytes different. Just skip matching that. llvm-svn: 210364
* Remove DWARF3 testing of test/DebugInfo/X86/gnu-public-names.llDavid Blaikie2014-06-061-88/+1
| | | | | | | | | | | | | | | | | This was added to test that DW_AT_GNU_pubnames used sec_offset in DWARF4 and data4 in DWARF3 and below. Since then we've updated DW_AT_GNU_pubnames to be a flag, rather than a section offset anyway. Granted this still differs between DWARF 3 and DWARF 4 (FORM_flag_present versun FORM_flag) but it doesn't seem worthwhile testing that codepath again here. It's covered adequately in many other test cases. And while I'm here, don't hardcode the byte size of the compile unit - it's not relevant to this test and just makes it brittle if/when anything changes in the way this CU is emitted. llvm-svn: 210362
* XFAIL: test/DebugInfo/missing-abstract-variable.ll on s390x as wellUlrich Weigand2014-06-051-1/+1
| | | | llvm-svn: 210264
* PR19388: DebugInfo: Emit dead arguments in their originally declared order.David Blaikie2014-06-051-0/+80
| | | | | | | | | | | | | | | | | | | | | | | 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
* Use AArch64 instead of now removed ARM64 in test configsAlexey Samsonov2014-06-051-1/+1
| | | | llvm-svn: 210229
* DebugInfo: Reapply r209984 (reverted in r210143), asserting that abstract ↵David Blaikie2014-06-041-9/+14
| | | | | | | | | | | | | | | | | 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
* XFAIL: test/DebugInfo/missing-abstract-variable.ll on mips and ppc64 due to ↵David Blaikie2014-06-041-0/+5
| | | | | | an inlined parameter that goes missing. llvm-svn: 210200
* DebugInfo: Partial revert r209984 due to more cases where abstract ↵David Blaikie2014-06-041-0/+181
| | | | | | | | | | | | | | | DbgVariables do not have associated DIEs. Along with a test case to demonstrate that due to inlining order there are cases where abstract variable DIEs are not constructed since the abstract subprogram was built due to a previous inlining that optimized away those variables. This produces incorrect debug info (the 'missing' abstract variable causes the inlined instance of that variable to be emitted with a full description (name, line, file) rather than referencing the abstract origin), but this commit at least ensures that it doesn't crash... llvm-svn: 210143
* DebugInfo: Assert that DbgVariables have associated DIEsDavid Blaikie2014-06-011-0/+391
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix typosAlp Toker2014-05-311-1/+1
| | | | llvm-svn: 209982
* No need for those tests to go thru llvm-as and/or llvm-dis.Arnaud A. de Grandmaison2014-05-271-1/+1
| | | | | | opt can handle them by itself. llvm-svn: 209689
* DebugInfo: Create abstract function definitions even when concrete ↵David Blaikie2014-05-273-17/+27
| | | | | | | | | | | | | | | 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: Lazily construct subprogram definition DIEs.David Blaikie2014-05-278-59/+60
| | | | | | | | | | | | | | | | 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-277-25/+30
| | | | | | | | | | | | | | | | | | | | | 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: Fix argument ordering in test by adding argument numbering.David Blaikie2014-05-271-5/+19
| | | | | | | | | | This old test didn't have the argument numbering that's now squirelled away in the high bits of the line number in the DW_TAG_arg_variable metadata. Add the numbering and update the test to ensure arguments are in-order. llvm-svn: 209669
* DebugInfo: Test linkonce-odr functions under LTO.David Blaikie2014-05-261-0/+74
| | | | | | | | | | | | | | | | | | | | | | | This was previously regressed/broken by r192749 (reverted due to this issue in r192938) and I was about to break it again by accident with some more invasive changes that deal with the subprogram lists. So to avoid that and further issues - here's a test. It's a pretty basic test - in both r192749 and my impending case, this test would crash, but checking the basics (that we put a subprogram in just one of the two CUs) seems like a good start. We still get this wrong in weird ways if the linkonce-odr function happens to not be identical in the metadata (because it's defined in two different files (hence the # line directives in this test), etc) even though it meets the language requirements (identical token stream) for such a thing. That results in two subprogram DIEs, but only one of them gets the parameter and high/low pc information, etc. We probably need to use the DIRef infrastructure to deduplicate functions as we do types to address this issue - or perhaps teach the BC linker to remove the duplicate entries in subprogram lists? llvm-svn: 209614
* DebugInfo: Fix inlining with #file directives a little harderDavid Blaikie2014-05-251-0/+3
| | | | | | | | | | | Seems my previous fix was insufficient - we were still not adding the inlined function to the abstract scope list. Which meant it wasn't flagged as inline, didn't have nested lexical scopes in the abstract definition, and didn't have abstract variables - so the inlined variable didn't reference an abstract variable, instead being described completely inline. llvm-svn: 209602
* Streamline test case by avoiding a temporary file and piping llc output ↵David Blaikie2014-05-251-2/+1
| | | | | | | | | straight to llvm-dwarfdump We still do temporary files in many cases, just updating this particular one because I was debugging it and made this change while doing so. llvm-svn: 209601
* CodeGen: Make MachineBasicBlock::back skip to the beginning of the last bundle.Benjamin Kramer2014-05-242-0/+78
| | | | | | | | | | | | This makes front/back symmetric with begin/end, avoiding some confusion. Added instr_front/instr_back for the old behavior, corresponding to instr_begin/instr_end. Audited all three in-tree users of back(), all of them look like they don't want to look inside bundles. Fixes an assertion (PR19815) when generating debug info on mips, where a delay slot was bundled at the end of a branch. llvm-svn: 209580
* AArch64/ARM64: move ARM64 into AArch64's placeTim Northover2014-05-242-4/+0
| | | | | | | | | | | | | | | This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for consistency. "ARM64" test directories are also moved, and tests that began their life in ARM64 use an arm64 triple, those from AArch64 use an aarch64 triple. Both should be equivalent though. This finishes the AArch64 merge, and everyone should feel free to continue committing as normal now. llvm-svn: 209577
* AArch64/ARM64: remove AArch64 from tree prior to renaming ARM64.Tim Northover2014-05-243-153/+1
| | | | | | | | | | | | | | | | I'm doing this in two phases for a better "git blame" record. This commit removes the previous AArch64 backend and redirects all functionality to ARM64. It also deduplicates test-lines and removes orphaned AArch64 tests. The next step will be "git mv ARM64 AArch64" and rewire most of the tests. Hopefully LLVM is still functional, though it would be even better if no-one ever had to care because the rename happens straight afterwards. llvm-svn: 209576
* DebugInfo: Generalize some tests to handle variations in attribute ordering.David Blaikie2014-05-2310-52/+65
| | | | | | | | | | | | | | | | In an effort to fix inlined debug info in situations where the out of line definition of a function preceeds any inlined usage, the order in which some attributes are added to subprogram DIEs may change. (in essence, definition-necessary attributes like DW_AT_low_pc/high_pc will be added immediately, but the names, types, and other features will be delayed to module end where they may either be added to the subprogram DIE or instead reference an abstract definition for those values) These tests can be generalized to be resilient to this change. 5 or so tests actually have to be incompatibly changed to cope with this reordering and will go along with the change that affects the order. llvm-svn: 209554
* DebugInfo: Generalize a test case to not depend on abbreviation numbering.David Blaikie2014-05-231-8/+8
| | | | | | | It's an unnecessary detail for this test and just gets in the way when making unrelated changes to the output in this test. llvm-svn: 209553
* DebugInfo: Put concrete definitions referencing abstract definitions in the ↵David Blaikie2014-05-231-0/+92
| | | | | | | | | | | | | | | | | | | 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
* DebugInfo: Fix cross-CU references for scopes (and variables within those ↵David Blaikie2014-05-231-0/+6
| | | | | | | | scopes) in abstract definitions of cross-CU inlined functions Found by Adrian Prantl during post-commit review of r209335. llvm-svn: 209498
* Revert "DebugInfo: Don't put fission type units in comdat sections."David Blaikie2014-05-211-18/+2
| | | | | | | | | 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-0/+124
| | | | | | | | | | | | | | | | 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-0/+3
| | | | | | reference their abstract origins. llvm-svn: 209327
* Move MCOptions that aren't shared between programs into their specificEric Christopher2014-05-211-1/+1
| | | | | | program and have them initialize the MCOptions struct explicitly. llvm-svn: 209321
* DebugInfo: Simplify subprogram declaration creation/references and ↵David Blaikie2014-05-214-17/+18
| | | | | | | | accidentally refix PR11300. Also simplifies the linkage name handling a little too. llvm-svn: 209311
* Add a comment here.Eric Christopher2014-05-211-0/+1
| | | | llvm-svn: 209262
* Move this test to the backend from the frontend.Eric Christopher2014-05-201-0/+50
| | | | llvm-svn: 209259
* Move the function and data section flags into the options struct andEric Christopher2014-05-201-1/+1
| | | | | | | | | | make the functions to set them non-static. Move and rename the llvm specific backend options to avoid conflicting with the clang option. Paired with a backend commit to update. llvm-svn: 209238
* PR19767: DebugInfo emission of pointer constants.David Blaikie2014-05-201-0/+51
| | | | | | | | | | | | | | | | | In refactoring DwarfUnit::isUnsignedDIType I restricted it to only work on values with signedness (unsigned or signed), asserting on anything else (which did uncover some bugs). But it turns out that we do need to emit constants of signless data, such as pointer constants - only null pointer constants are known to need this so far, but it's conceivable that there might be non-null pointer constants at some point (hardcoded address offsets for device drivers?). This patch just uses 'unsigned' for signless data such as pointer constants. Arguably we could use signless representations (DW_FORM_dataN) instead, allowing a trinary result from isUnsignedDIType (signed, unsigned, signless), but this seems reasonable for now. llvm-svn: 209223
* DebugInfo: Emit function definitions within their namespace scope.David Blaikie2014-05-201-0/+44
| | | | | | | | 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
* Follow up to 209187, updating a test to use FileCheck. Needed to ignore an ↵David Blaikie2014-05-201-1/+2
| | | | | | extra DW_TAG_class_type llvm-svn: 209188
* Update test/DebugInfo/2010-04-06-NestedFnDbgInfo.ll to use FileCheck.David Blaikie2014-05-201-2/+17
| | | | llvm-svn: 209187
* DebugInfo: Assume all subprogram DIEs have been created before any abstract ↵David Blaikie2014-05-191-1/+1
| | | | | | | | | | | | | | 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-0/+3
| | | | | | | | | | | | | | | | | 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-6/+35
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Kill symbolization functionality in llvm-dwarfdump. We have llvm-symbolizer ↵Alexey Samsonov2014-05-196-97/+62
| | | | | | for that. llvm-svn: 209152
* [DWARF parser] Teach DIContext to fetch short (non-linkage) function names ↵Alexey Samsonov2014-05-171-1/+7
| | | | | | | | | | for a given address. Change --functions option in llvm-symbolizer tool to accept values "none", "short" or "linkage". Update the tests and docs accordingly. llvm-svn: 209050
* DebugInfo: Handle emitting constants of C++ unicode character type.David Blaikie2014-05-161-21/+34
| | | | | | | | Patch by Stephan Tolksdorf! (with some test case stuff by me) Differential Revision: http://reviews.llvm.org/D3810 llvm-svn: 209037
* DebugInfo: Assume the CU's Subprogram list only contains definitions.David Blaikie2014-05-162-2/+2
| | | | | | | | | | | 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
* DebugInfo: Don't put fission type units in comdat sections.David Blaikie2014-05-151-2/+18
| | | | | | | | | 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: Sure up subprogram variable list handling with more assertions ↵David Blaikie2014-05-1417-76/+36
| | | | | | | | | | | | 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
OpenPOWER on IntegriCloud