summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
* Removing empty tests from failed revertRenato Golin2014-09-241-0/+0
| | | | llvm-svn: 218417
* Revert 218406 - Refactor the RelocVisitor::visit methodRenato Golin2014-09-241-18/+0
| | | | llvm-svn: 218416
* Revert 218411 - XFAIL reloc test on x86/hexagonRenato Golin2014-09-241-1/+0
| | | | llvm-svn: 218413
* XFAIL reloc test on x86/hexagonRenato Golin2014-09-241-0/+1
| | | | llvm-svn: 218411
* Refactor the RelocVisitor::visit methodRenato Golin2014-09-241-0/+18
| | | | | | | | | | | | | | | | | | This change replaces the brittle if/else chain of string comparisons with a switch statement on the detected target triple, removing the need for testing arbitrary architecture names returned from getFileFormatName, whose primary purpose seems to be for display (user-interface) purposes. The visitor now takes a reference to the object file, rather than its arbitrary file format name to figure out whether the file is a 32 or 64-bit object file and what the detected target triple is. A set of tests have been added to help show that the refactoring processes relocations for the same targets as the original code. Patch by Charlie Turner. llvm-svn: 218406
* Revert "Refactor the RelocVisitor::visit method"Kaelyn Takata2014-09-241-26/+0
| | | | | | | | | This reverts commit faac033f7364bb4226e22c8079c221c96af10d02. The test depends on all targets to be enabled in llc in order to pass, and needs to be rewritten/refactored to not have that dependency. llvm-svn: 218393
* Refactor the RelocVisitor::visit methodRenato Golin2014-09-241-0/+26
| | | | | | | | | | | | | | | | | | This change replaces the brittle if/else chain of string comparisons with a switch statement on the detected target triple, removing the need for testing arbitrary architecture names returned from getFileFormatName, whose primary purpose seems to be for display (user-interface) purposes. The visitor now takes a reference to the object file, rather than its arbitrary file format name to figure out whether the file is a 32 or 64-bit object file and what the detected target triple is. A set of tests have been added to help show that the refactoring processes relocations for the same targets as the original code. Patch by Charlie Turner. llvm-svn: 218388
* Fix segfault in AArch64 backend with -g and -mbig-endianOliver Stannard2014-09-231-0/+22
| | | | | | | Fix a null pointer dereference when trying to swap the endianness of fixups in the .eh_frame section in the AArch64 backend. llvm-svn: 218311
* Fix a small typo in the test commentTimur Iskhodzhanov2014-09-231-4/+4
| | | | llvm-svn: 218306
* Fix a test introduced in r218246 to work also on Windows.Frederic Riss2014-09-221-2/+2
| | | | llvm-svn: 218255
* [dwarfdump] Dump full filenames as DW_AT_(decl|call)_file attribute valuesFrederic Riss2014-09-222-17/+14
| | | | | | | | | | Reviewers: dblaikie samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5192 llvm-svn: 218246
* Allow DWARFDebugInfoEntryMinimal::getSubroutineName to resolve cross-unit ↵Frederic Riss2014-09-223-0/+26
| | | | | | | | | | | | | | references. Summary: getSubroutineName is currently only used by llvm-symbolizer, thus add a binary test containing a cross-cu inlining example. Reviewers: samsonov, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5394 llvm-svn: 218245
* Update tests which broke from r218189David Majnemer2014-09-206-10/+10
| | | | llvm-svn: 218191
* Fix test case to be portable to different architectures.David Blaikie2014-09-191-5/+7
| | | | llvm-svn: 218134
* Omit DW_TAG_subprograms for subprograms without inlined subroutines when ↵David Blaikie2014-09-193-36/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). llvm-svn: 218129
* Omit DW_AT_frame_base under -gmlt for sizeDavid Blaikie2014-09-191-2/+0
| | | | llvm-svn: 218100
* Omit all the extra static attributes on subprograms in -gmltDavid Blaikie2014-09-191-0/+9
| | | | | | | | This omission will be done in a fancier manner once we're dealing with "put gmlt in the skeleton CUs under fission" - it'll have to be conditional on the kind of CU we're emitting into (skeleton or gmlt). llvm-svn: 218098
* DebugInfo: Do not use DW_FORM_GNU_addr_index in skeleton CUs, GDB 7.8 errors ↵David Blaikie2014-09-071-2/+4
| | | | | | | | | | on this. It's probably not a huge deal to not do this - if we could, maybe the address could be reused by a subprogram low_pc and avoid an extra relocation, but it's just one per CU at best. llvm-svn: 217338
* MC: correct DWARF line info for PE/COFFSaleem Abdulrasool2014-09-061-0/+6
| | | | | | | | | DWARF address ranges contain a reference to the debug_info section. This offset is an absolute relocation except on non-PE/COFF targets where it is section relative. We would emit this incorrectly, and trying to map the debug info from the address would fail. llvm-svn: 217317
* [DWARF parser] Fix nasty memory corruption in .dwo files handling.Alexey Samsonov2014-09-054-0/+30
| | | | | | | Forge a test case where llvm-symbolizer has to use external .dwo file to produce the inlining information. llvm-svn: 217270
* [dwarfdump] Dump DW_AT_(decl|call)_line attribute values as decimal values.Frederic Riss2014-09-053-15/+15
| | | | llvm-svn: 217232
* Reapply "[dwarfdump] Add missing DW_LANG_Mips_Assembler case to ↵Frederic Riss2014-09-051-1/+1
| | | | | | | | LanguageString()" This commit was reverted in r217183, but is OK to go in again now that its dependency is commited (as of r217186). llvm-svn: 217231
* MC: correct DWARF header for PE/COFF assembly inputSaleem Abdulrasool2014-09-051-0/+2
| | | | | | | | | | | The header contains an offset to the DWARF line table for the CU. The offset must be section relative for COFF and absolute for others. The non-assembly code path for the DWARF header generation already has the correct emission for the headers. This corrects the assembly input path. This was identified by BFD objecting to the LLVM generated DWARF information. llvm-svn: 217222
* [ dwarfdump ] Add symbolic dump of known DWARF attribute values.Frederic Riss2014-09-046-23/+23
| | | | | | | | | | Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5187 llvm-svn: 217186
* Revert "[dwarfdump] Add missing DW_LANG_Mips_Assembler case to LanguageString()"Frederic Riss2014-09-041-1/+1
| | | | | | | | This reverts commit 93c7e6161e1adbd2c7ac81fa081823183035cb64. This commit got approved first, but was dependant on another one going in (The one pretty printing attribute values). I'll reapply when the other one is in. llvm-svn: 217183
* [dwarfdump] Add missing DW_LANG_Mips_Assembler case to LanguageString()Frederic Riss2014-09-041-1/+1
| | | | | | | | | | Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5193 llvm-svn: 217182
* DebugInfo: Elide lexical scopes which only contain other (inline or lexical) ↵David Blaikie2014-08-314-23/+7
| | | | | | | | | | | | | | | | | | | | | scopes. DW_TAG_lexical_scopes inform debuggers about the instruction range for which a given variable (or imported declaration/module/etc) is valid. If the scope doesn't itself contain any such entities, it's a waste of space and should be omitted. We were correctly doing this for entirely empty leaves, but not for intermediate nodes. Reduces total (not just debug sections) .o file size for a bootstrap -gmlt LLVM by 22% and bootstrap -gmlt clang executable by 13%. The wins for a full -g build will be less as a % (and in absolute terms), but should still be substantial - with some of that win being fewer relocations, thus more substantiall reducing link times than fewer bytes alone would have. llvm-svn: 216861
* Debug info: Add a new explicit DIDescriptor flag for the "public" accessAdrian Prantl2014-08-293-5/+155
| | | | | | | | | | specifier and change the default behavior to only emit the DW_AT_accessibility(public) attribute when the isPublic() is explicitly set. rdar://problem/18154959 llvm-svn: 216799
* Remove unnecessary regex in test pattern per dblaikie suggestion.Frederic Riss2014-08-292-6/+6
| | | | llvm-svn: 216733
* Use DwarfDebug::attachLowHighPC for the compilation unit DIE.Frederic Riss2014-08-292-8/+26
| | | | llvm-svn: 216719
* Remove type unit skeletons. GDB no longer needs them & this saves a heap of ↵David Blaikie2014-08-271-18/+6
| | | | | | space. llvm-svn: 216521
* Fix a couple of debug info test cases to match the metadata schema change in ↵David Blaikie2014-08-271-1/+1
| | | | | | | | r216239 Found these while testing something else. llvm-svn: 216505
* Use DILexicalBlockFile, rather than DILexicalBlock, to track discriminator ↵David Blaikie2014-08-213-7/+7
| | | | | | | | | | | | | | | changes to ensure discriminator changes don't introduce new DWARF DW_TAG_lexical_blocks. Somewhat unnoticed in the original implementation of discriminators, but it could cause instructions to end up in new, small, DW_TAG_lexical_blocks due to the use of DILexicalBlock to track discriminator changes. Instead, use DILexicalBlockFile which we already use to track file changes without introducing new scopes, so it works well to track discriminator changes in the same way. llvm-svn: 216239
* Reapply [FastISel][X86] Use XOR to materialize the "0" value (r215594).Juergen Ributzka2014-08-191-1/+1
| | | | | | | Note: This was originally reverted to track down a buildbot error. Reapply without any modifications. llvm-svn: 216011
* Revert several FastISel commits to track down a buildbot error.Juergen Ributzka2014-08-141-1/+1
| | | | | | | | | | | | This reverts: r215595 "[FastISel][X86] Add large code model support for materializing floating-point constants." r215594 "[FastISel][X86] Use XOR to materialize the "0" value." r215593 "[FastISel][X86] Emit more efficient instructions for integer constant materialization." r215591 "[FastISel][AArch64] Make use of the zero register when possible." r215588 "[FastISel] Let the target decide first if it wants to materialize a constant." r215582 "[FastISel][AArch64] Cleanup constant materialization code. NFCI." llvm-svn: 215673
* [FastISel][X86] Use XOR to materialize the "0" value.Juergen Ributzka2014-08-131-1/+1
| | | | llvm-svn: 215594
* DebugLocEntry: Restore the comparison predicate from before theAdrian Prantl2014-08-121-0/+1
| | | | | | | | | refactoring in 215384. This way it can unique multiple entries describing the same piece even if they don't have the exact same location. (The same piece may get merged in and be added from OpenRanges). There ought to be a more elegant solution for this, though. llvm-svn: 215418
* Fix llvm/test/DebugInfo/X86/recursive_inlining.ll to use %llc_dwarf.NAKAMURA Takumi2014-08-081-1/+1
| | | | llvm-svn: 215181
* Make these regexes stricter by disallowing any additional characters in the ↵Adrian Prantl2014-08-071-1/+1
| | | | | | | | output. Thanks to dblaikie for pointing this out! llvm-svn: 215166
* Add a separate testcase for a DWARF expression describing a value in aAdrian Prantl2014-08-071-0/+63
| | | | | | subregister. llvm-svn: 215161
* DebugInfo: Fix overwriting/loss of inlined arguments to recursively inlined ↵David Blaikie2014-08-071-0/+275
| | | | | | | | | | | | | | | | | | | | | functions. Due to an unnecessary special case, inlined arguments that happened to be from the same function as they were inlined into were misclassified as non-inline arguments and would overwrite the non-inlined arguments. Assert that we never overwrite a function's arguments, and stop misclassifying inlined arguments as non-inline arguments to fix this issue. Excuse the rather crappy test case - handcrafted IR might do better, or someone who understands better how to tickle the inliner to create a recursive inlining situation like this (though it may also be necessary to tickle the variable in a particular way to cause it to be recorded in the MMI side table and go down this particular path for location information). llvm-svn: 215157
* DebugInfo: Make a test more portableJustin Bogner2014-08-071-2/+2
| | | | | | | | | mach-o doesn't like sections without segments, and elf is perfectly happy with commas in section names, so use a Darwin-like section name. Suggestion by Eric Christopher. llvm-svn: 215052
* DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation.David Blaikie2014-08-061-24/+35
| | | | | | | | | | | | | | | | | | | | | | Originally this test case tested the specified behavior (that -gmlt would not produce DW_AT_ranges and that when no CU DW_AT_ranges were produced, no debug_ranges section (not even an empty list) would be produced) but then the ranges emission code was improved not to create ranges of a single element (instead favoring high_pc/low_pc) and so this test case no longer exercised the -gmlt portion of the behavior. This caused me some confusion when reading the comments and trying to update this test case for future changes to -gmlt. I've made this test resilient to those changes (by using the {{DW_TAG|NULL}} pattern to block the end of the attribute search at the end of the CU's attribute list without mandating that it must (or must not) be followed by another tag (the future changes to -gmlt should produce no subprograms in this CU)) Fix the test case to have two functions in distinct sections to force the use of DW_AT_ranges. llvm-svn: 214985
* DebugInfo: Assert that any CU for which debug_loc lists are emitted, has at ↵David Blaikie2014-08-0622-23/+23
| | | | | | | | | | | | | | | | least one range. This was coming in weird debug info that had variables (and hence debug_locs) but was in GMLT mode (because it was missing the 13th field of the compile_unit metadata) so no ranges were constructed. We should always have at least one range for any CU with a debug_loc in it - because the range should cover the debug_loc. The assertion just ensures that the "!= 1" range case inside the subsequent loop doesn't get entered for the case where there are no ranges at all, which should never reach here in the first place. llvm-svn: 214939
* DebugInfo: Fix a bunch of tests that, owing to their compile_unit metadata ↵David Blaikie2014-08-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | not including a 13th field, had some subtle behavior. Without the 13th field, the "emission kind" field defaults to 0 (which is not equal to either of the values of the emission kind enum (1 == full debug info, 2 == line tables only)). In this particular instance, the comparison with "FullDebugInfo" was done when adding elements to the ranges list - so for these test cases no values were added to the ranges list. This got weirder when emitting debug_loc entries as the addresses should be relative to the range of the CU if the CU has only one range (the reasonable assumption is that if we're emitting debug_loc lists for a CU that CU has at least one range - but due to the above situation, it has zero) so the ranges were emitted relative to the start of the section rather than relative to the start of the CU's singular range. Fix these tests by accounting for the difference in the description of debug_loc entries (in some cases making the test ignorant to these differences, in others adding the extra label difference expression, etc) or the presence/absence of high/low_pc on the CU, and add the 13th field to their CUs to enable proper "full debug info" emission here. In a future commit I'll fix up a bunch of other test cases that are not so rigorously depending on this behavior, but still doing similarly weird things due to the missing 13th field. llvm-svn: 214937
* Cleanup this test some more.Adrian Prantl2014-08-011-8/+8
| | | | llvm-svn: 214591
* Add the missing target triple to this testcase.Adrian Prantl2014-08-011-0/+3
| | | | llvm-svn: 214590
* Debug info: Infrastructure to support debug locations for fragmentedAdrian Prantl2014-08-013-0/+273
| | | | | | | | | | | | | | | | | | | | | | | | variables (for example, by-value struct arguments passed in registers, or large integer values split across several smaller registers). On the IR level, this adds a new type of complex address operation OpPiece to DIVariable that describes size and offset of a variable fragment. On the DWARF emitter level, all pieces describing the same variable are collected, sorted and emitted as DWARF expressions using the DW_OP_piece and DW_OP_bit_piece operators. http://reviews.llvm.org/D3373 rdar://problem/15928306 What this patch doesn't do / Future work: - This patch only adds the backend machinery to make this work, patches that change SROA and SelectionDAG's type legalizer to actually create such debug info will follow. (http://reviews.llvm.org/D2680) - Making the DIVariable complex expressions into an argument of dbg.value will reduce the memory footprint of the debug metadata. - The sorting/uniquing of pieces should be moved into DebugLocEntry, to facilitate the merging of multi-piece entries. llvm-svn: 214576
* Use "weak alias" instead of "alias weak"Rafael Espindola2014-07-301-2/+2
| | | | | | | | | | | | | | | | | | | | | Before this patch we had @a = weak global ... but @b = alias weak ... The patch changes aliases to look more like global variables. Looking at some really old code suggests that the reason was that the old bison based parser had a reduction for alias linkages and another one for global variable linkages. Putting the alias first avoided the reduce/reduce conflict. The days of the old .ll parser are long gone. The new one parses just "linkage" and a later check is responsible for deciding if a linkage is valid in a given context. llvm-svn: 214355
* [Debug Info] remove DITrivialType and use null to represent unspecified param.Manman Ren2014-07-291-3/+2
| | | | | | | | | | | | Per feedback on r214111, we are going to use null to represent unspecified parameter. If the type array is {null}, it means a function that returns void; If the type array is {null, null}, it means a variadic function that returns void. In summary if we have more than one element in the type array and the last element is null, it is a variadic function. rdar://17628609 llvm-svn: 214189
OpenPOWER on IntegriCloud