summaryrefslogtreecommitdiffstats
path: root/llvm/test/tools/llvm-dwarfdump/X86
Commit message (Collapse)AuthorAgeFilesLines
...
* [DWARF] Set discriminator to 0 for DW_LNS_copyFangrui Song2019-04-111-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Make DW_LNS_copy set the discriminator register to 0, to conform to DWARF 4 & 5: "Then it sets the discriminator register to 0, and sets the basic_block, prologue_end and epilogue_begin registers to false." Because all of DW_LNE_end_sequence, DN_LNS_copy, and special opcodes reset discriminator to 0, we can move discriminator=0 to appendRowToMatrix. Also, make DW_LNS_copy print before appending the row, as it is similar to a address+=0,line+=0 special opcode, which prints before appending the row. Reviewers: dblaikie, probinson, aprantl Reviewed By: dblaikie Subscribers: danielcdh, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60364 llvm-svn: 358148
* [dwarfdump] Remove bogus verifier errorJonas Devlieghere2019-04-031-7/+0
| | | | | | | | The standard doesn't require a DW_TAG_variable, DW_TAG_formal_parameter or DW_TAG_constant to A DW_AT_type attribute describing the type of the variable. It only specifies that it *can* have one. llvm-svn: 357628
* [DWARFFormValue] Don't consider DW_FORM_data4/8 to be section offsets.Jonas Devlieghere2019-03-052-0/+646
| | | | | | | | | | | | | | | | | | | | | | | | | | | When dumping ToT clan's debug info with dwarfdump, we were seeing an error saying that that the location list overflows the debug_loc section. After reducing the testcase we figured out that we were interpreting the DW_FORM_data4 as a section offset. In DWARF3 DW_FORM_data4 and DW_FORM_data8 served also as a section offset. Until now we didn't check check for the DWARF version, because some producers (read old versions of clang) were still emitting this. The relevant code/comment was added in 2013, and I believe it's now reasonable to start checking the version. The FormValue class is a little bit of a mess because it cashes the DWARF unit and context when it extracted the value itself. Several methods of the class rely on it being present, or return an Optional for the code path that needs it. At the same time the FormValue class also used in places where there's no DWARF unit. For this patch I went with the least invasive change: checking the version from the CU when it's available. If it's not (because the form value was created from a value directly) we default to the old behavior. Differential revision: https://reviews.llvm.org/D58698 llvm-svn: 355456
* llvm-dwarfdump: Add new variable, parameter and inlining statistics; also ↵Caroline Tice2019-03-013-1/+1244
| | | | | | | | | | | | | function source location statistics. Add statistics for abstract origins, function, variable and parameter locations; break the 'variable' counts down into variables and parameters. Also update call site counting to check for DW_AT_call_{file,line} in addition to DW_TAG_call_site. Differential revision: https://reviews.llvm.org/D58849 llvm-svn: 355243
* [DebugInfo] Prep llvm-dwarfdump for typed DW5 ops.Markus Lavin2019-02-211-0/+124
| | | | | | | | | | | Adds llvm-dwarfdump support for pretty printing Dwarf5 expressions ops that reference a base type (right now only DW_OP_convert is added). Includes verification to verify that the ops operand is actually a DW_TAG_base_type DIE. Differential Revision: https://reviews.llvm.org/D58442 llvm-svn: 354552
* lvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined ↵Caroline Tice2019-02-083-3/+3
| | | | | | | | | | functions" statistic. DW_TAG_subprogram DIEs should not be counted in the inlined function statistic. This also addresses the source variables count, as that uses the inlined function count in its calculations. Differential revision: https://reviews.llvm.org/D57849 llvm-svn: 353491
* [DebugInfo]Print correct value for special opcode address incrementJames Henderson2019-02-061-1/+1
| | | | | | | | | | | The wrong variable was being used when printing the address increment in verbose output of .debug_line. This patch fixes this. Reviewed by: JDevlieghere Differential Revision: https://reviews.llvm.org/D57693 llvm-svn: 353288
* [DWARF v5] Fix DWARF emitter and consumer to produce/expect a uleb for a ↵Wolfgang Pieb2019-02-011-2/+2
| | | | | | | | | | location description's length. Reviewer: davide, JDevliegere Differential Revision: https://reviews.llvm.org/D57550 llvm-svn: 352889
* llvm-dwarfdump: Skip address index info (and dump only the address, if ↵David Blaikie2018-12-241-0/+77
| | | | | | | | found) when non-verbose dumping addrx forms There's a few bugs here still - demonstrated with FIXITs in the test. llvm-svn: 350046
* llvm-dwarfdump: Dump the section name/number for addr attributesDavid Blaikie2018-12-221-1/+1
| | | | llvm-svn: 350009
* llvm-dwarfdump: Improve/fix pretty printing of array dimensionsDavid Blaikie2018-12-191-3/+59
| | | | | | | | | | | | | | This is to address post-commit feedback from Paul Robinson on r348954. The original commit misinterprets count and upper bound as the same thing (I thought I saw GCC producing an upper bound the same as Clang's count, but GCC correctly produces an upper bound that's one less than the count (in C, that is, where arrays are zero indexed)). I want to preserve the C-like output for the common case, so in the absence of a lower bound the count (or one greater than the upper bound) is rendered between []. In the trickier cases, where a lower bound is specified, a half-open range is used (eg: lower bound 1, count 2 would be "[1, 3)" and an unknown parts use a '?' (eg: "[1, ?)" or "[?, 7)" or "[?, ? + 3)"). Reviewers: aprantl, probinson, JDevlieghere Differential Revision: https://reviews.llvm.org/D55721 llvm-svn: 349670
* [llvm-dwarfdump] - Do not error out on R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 ↵George Rimar2018-12-181-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | relocations. This is https://bugs.llvm.org/show_bug.cgi?id=39992, If we have the following code (test.cpp): thread_local int tdata = 24; and build an .o file with debug information: clang --target=x86_64-pc-linux -c bar.cpp -g Then object produced may have R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 relocations. (clang emits R_X86_64_DTPOFF64 and gcc emits R_X86_64_DTPOFF32 for the code above for me) Currently, llvm-dwarfdump fails to compute this TLS relocation when dumping object and reports an error: failed to compute relocation: R_X86_64_DTPOFF64, Invalid data was encountered while parsing the file This relocation represents the offset in the TLS block and resolved by the linker, but this info is unavailable at the point when the object file is dumped by this tool. The patch adds the simple evaluation for such relocations to avoid emitting errors. Resulting behavior seems to be equal to GNU dwarfdump. Differential revision: https://reviews.llvm.org/D55762 llvm-svn: 349476
* DebugInfo/DWARF: Pretty print subroutine typesDavid Blaikie2018-12-121-0/+45
| | | | | | | | Doesn't handle varargs and other fun things, but it's a start. (also doesn't print these strictly as valid C++ when it's a pointer to function, it'll print as "void(int)*" instead of "void (*)(int)") llvm-svn: 348965
* DebugInfo/DWARF: Improve dumping of pointers to members ('int foo::*' rather ↵David Blaikie2018-12-121-3/+17
| | | | | | than 'int*') llvm-svn: 348962
* llvm-dwarfdump: Dump array dimensions in stringified type namesDavid Blaikie2018-12-121-0/+179
| | | | llvm-svn: 348954
* [llvm-dwarfdump] - Simplify the test case.George Rimar2018-12-061-191/+45
| | | | | | | | | | The test was fully rewritten for simplification. New test code was suggested by David Blaikie. Differential revision: https://reviews.llvm.org/D55261 llvm-svn: 348464
* [llvm-dwarfdump] - Dump the older versions of .eh_frame/.debug_frame correctly.George Rimar2018-12-041-0/+51
| | | | | | | | | | | | | | | | | | | | | | The issue is the following. DWARF 2 used version 1 for .debug_frame. (Appendix G, p. 416 http://dwarfstd.org/doc/DWARF5.pdf) lib/MC now always sets version 1 for .eh_frame (and sets 1-4 versions for .debug_frame correctly): https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1530 https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1562 https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1602 In version 1, return_address_register was defined as ubyte, while other versions switched to uleb128. (p 62, http://www.dwarfstd.org/doc/dwarf-2.0.0.pdf) Patch teaches llvm-dwarfdump about this difference. Differential revision: https://reviews.llvm.org/D54860 llvm-svn: 348242
* [llvm-dwarfdump] - Stop printing the bogus empty section name on invalid dwarf.George Rimar2018-12-031-0/+197
| | | | | | | | | | | | | | | | | | | | | When there is no .debug_addr section for some reason, llvm-dwarfdump would print the bogus empty section name when dumping ranges in .debug_info: DW_AT_ranges [DW_FORM_rnglistx] (indexed (0x0) rangelist = 0x00000004 [0x0000000000000000, 0x0000000000000001) "" [0x0000000000000000, 0x0000000000000002) "") That happens because of the code which uses 0 (zero) as a section index as a default value. The code should use -1ULL instead because technically 0 is a valid zero section index in ELF and -1ULL is a special constant used that means "no section available". This is mostly a fix for the overall correctness/safety of the code, but a test case is provided too. Differential revision: https://reviews.llvm.org/D55113 llvm-svn: 348115
* Revert r347490 as it breaks address sanitizer buildsLuke Cheeseman2018-11-231-1/+1
| | | | llvm-svn: 347499
* Revert r343341Luke Cheeseman2018-11-231-1/+1
| | | | | | | - Cannot reproduce the build failure locally and the build logs have been deleted. llvm-svn: 347490
* Add total function byte size and inline function byte size to ↵Greg Clayton2018-11-091-0/+3
| | | | | | | | "llvm-dwarfdump --statistics" Differential Revision: https://reviews.llvm.org/D54217 llvm-svn: 346531
* [DWARF v5] Verifier: Add checks for DW_FORM_strx* forms.Wolfgang Pieb2018-11-032-2/+90
| | | | | | | | | Adding functionality to the DWARF verifier for DWARF v5 strx* forms which index into the string offsets table. Differential Revision: https://reviews.llvm.org/D54049 llvm-svn: 346061
* Revert "Revert "DebugInfo: reduce DIE range verification on object files""Saleem Abdulrasool2018-10-281-0/+57
| | | | | | | This reverts commit 836c763dadbd9478fa35b1a291a38bf17aa206ba. Default initialize the values that MSAN caught. llvm-svn: 345482
* Revert "DebugInfo: reduce DIE range verification on object files"Vlad Tsyrklevich2018-10-271-57/+0
| | | | | | | This reverts commits r345441 and r345444, they were causing msan buildbot failures. llvm-svn: 345457
* test: add missing -tripleSaleem Abdulrasool2018-10-271-1/+1
| | | | | | | Ensure that the test builds for x86_64 as it is an assembly test. This should repair the buildbots. llvm-svn: 345444
* DebugInfo: reduce DIE range verification on object filesSaleem Abdulrasool2018-10-271-0/+57
| | | | | | | | Relocatable content may have overlapping ranges until the sections are finalized. This reduces the amount of verification that is done on an object file so that invalid errors are not raised. llvm-svn: 345441
* [llvm-dwarfdump] - Fix incorrect parsing of the DW_LLE_startx_lengthGeorge Rimar2018-10-251-0/+27
| | | | | | | | | | | | | | | | | As was already mentioned in comments for D53364, DWARF 5 spec says about DW_LLE_startx_length: "This is a form of bounded location description that has two unsigned ULEB operands. The first value is an address index (into the .debug_addr section) that indicates the beginning of the address range over which the location is valid. The second value is the length of the range. ") Currently, the length is always parsed as U32. Patch change the behavior to parse DW_LLE_startx_length as ULEB128 for DWARF 5 and keeps it as U32 for DWARF4+(pre-DWARF5) for compatibility. Differential revision: https://reviews.llvm.org/D53564 llvm-svn: 345254
* Make llvm-dwarfdump -name work on type units.Paul Robinson2018-10-241-0/+100
| | | | | | Differential Revision: https://reviews.llvm.org/D53672 llvm-svn: 345203
* llvm-dwarfdump: Support RLE_addressx and RLE_startx_length in .debug_rnglistsDavid Blaikie2018-10-201-3/+24
| | | | llvm-svn: 344835
* llvm-dwarfdump: Extend --name to also search DW_AT_linkage_name.Adrian Prantl2018-10-091-0/+5
| | | | | | rdar://problem/45132695 llvm-svn: 344079
* [DWARF] Make llvm-dwarfdump display the .debug_loc.dwo section. Fixes PR38991.Wolfgang Pieb2018-10-091-0/+20
| | | | | | | | Reviewer: dblaikie Differential Revision: https://reviews.llvm.org/D52444 llvm-svn: 344068
* [DebugInfo] Add support for DWARF5 call site-related attributesVedant Kumar2018-10-051-0/+376
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DWARF v5 introduces DW_AT_call_all_calls, a subprogram attribute which indicates that all calls (both regular and tail) within the subprogram have call site entries. The information within these call site entries can be used by a debugger to populate backtraces with synthetic tail call frames. Tail calling frames go missing in backtraces because the frame of the caller is reused by the callee. Call site entries allow a debugger to reconstruct a sequence of (tail) calls which led from one function to another. This improves backtrace quality. There are limitations: tail recursion isn't handled, variables within synthetic frames may not survive to be inspected, etc. This approach is not novel, see: https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=jelinek.pdf This patch adds an IR-level flag (DIFlagAllCallsDescribed) which lowers to DW_AT_call_all_calls. It adds the minimal amount of DWARF generation support needed to emit standards-compliant call site entries. For easier deployment, when the debugger tuning is LLDB, the DWARF requirement is adjusted to v4. Testing: Apart from check-{llvm, clang}, I built a stage2 RelWithDebInfo clang binary. Its dSYM passed verification and grew by 1.4% compared to the baseline. 151,879 call site entries were added. rdar://42001377 Differential Revision: https://reviews.llvm.org/D49887 llvm-svn: 343883
* Format the dwarfdump --statistics version as an integer instead of a string.Adrian Prantl2018-10-051-0/+1
| | | | llvm-svn: 343864
* Revert r343317Luke Cheeseman2018-09-281-1/+1
| | | | | | - asan buildbots are breaking and I need to investigate the issue llvm-svn: 343341
* Reapply changes reverted by r343235Luke Cheeseman2018-09-281-1/+1
| | | | | | | | - Add fix so that all code paths that create DWARFContext with an ObjectFile initialise the target architecture in the context - Add an assert that the Arch is known in the Dwarf CallFrameString method llvm-svn: 343317
* llvm-dwarfdump --statistics: Unique abstract origins across multiple CUs.Adrian Prantl2018-09-212-0/+378
| | | | | | | | Instead of indexing local variables by DIE offset, use the variable name + the path through the lexical block tree. This makes the lookup key consistent across duplicate abstract origins in different CUs. llvm-svn: 342776
* [dwarfdump] Verify DW_AT_type is set and points to a compatible DIE.Jonas Devlieghere2018-09-211-2/+20
| | | | | | | | | | | | | This extends the verifier to catch three new errors: * Missing DW_AT_type attributes for DW_TAG_formal_parameter, DW_TAG_variable and DW_TAG_array_type. * Valid references for DW_AT_type pointing to a non-type tag. Differential revision: https://reviews.llvm.org/D52223 llvm-svn: 342713
* [dwarfdump] Verify compatibility of attribute TAGs.Jonas Devlieghere2018-09-211-0/+386
| | | | | | | | | Verify that DW_AT_specification and DW_AT_abstract_origin reference a DIE with a compatible tag. Differential revision: https://reviews.llvm.org/D38719 llvm-svn: 342712
* [dwarfdump] Improve -diff option by hiding more data.Jonas Devlieghere2018-09-041-0/+489
| | | | | | | | | | The -diff option makes it easy to diff dwarf by hiding addresses and offsets. However not all of them were hidden, which should be fixed by this patch. Differential revision: https://reviews.llvm.org/D51593 llvm-svn: 341377
* [DebugInfo] Have the verifier accept missing linkage names.Jonas Devlieghere2018-09-031-0/+646
| | | | | | | | | | | | | | | | | | According to the standard, for the .debug_names (the "dwarf accelerator tables"): > If a subprogram or inlined subroutine is included, and has a > DW_AT_linkage_name attribute, there will be an additional index entry > for the linkage name. For Swift we generate DW_structure_types with a linkage name and the verifier was incorrectly rejecting this. This patch fixes that by only considering the linkage name in those particular cases. The test is the "reduced" debug info of the failing swift test on swift.org. Differential revision: https://reviews.llvm.org/D51420 llvm-svn: 341311
* [DWARF] Support for .debug_addr (consumer)Victor Leschuk2018-07-3115-0/+343
| | | | | | | This patch implements basic support for parsing and dumping DWARFv5 .debug_addr section. llvm-svn: 338447
* [DWARF v5] Refactor range lists dumping by using a more generic way of ↵Wolfgang Pieb2018-07-232-26/+26
| | | | | | | | | | | | | handling tables of lists. The intent is to use it for location list tables as well. Change is almost NFC with the exception of the spelling of some strings used during dumping (all lowercase now). Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D49500 llvm-svn: 337763
* NFC - Various typo fixes in testsGabor Buella2018-07-041-5/+5
| | | | llvm-svn: 336268
* [DWARF/AccelTable] Remove getDIESectionOffset for DWARF v5 entriesPavel Labath2018-06-131-0/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This method was not correct for entries in DWO files as it assumed it could just add up the CU and DIE offsets to get the absolute DIE offset. This is not correct for the DWO files, as here the CU offset will reference the skeleton unit, whereas the DIE offset will be the offset in the full unit in the DWO file. Unfortunately, this means that we are not able to determine the absolute DIE offset using the information in the .debug_names section alone, which means we have to offload some of this work to the users of this class. To demonstrate how this can be done, I've added/fixed the ability to lookup entries using accelerator tables in DWO files in llvm-dwarfdump. To make this happen, I've needed to make two extra changes in other classes: - made the DWARFContext method to lookup a CU based on the section offset public. I've needed this functionality to lookup a CU, and this seems like a useful thing in general. - made DWARFUnit::getDWOId call extractDIEsIfNeeded. Before this, the DWOId was filled in only if the root DIE happened to be parsed before we called the accessor. Since the lazy parsing is supposed to happen under the hood, calling extractDIEsIfNeeded seems appropriate. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D48009 llvm-svn: 334578
* DWARFAcceleratorTable: fix equal_range iteratorsPavel Labath2018-05-312-6/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Both (Apple and DWARF5) implementations of the iterators had bugs which resulted in crashes if one attempted to iterate through the accelerator tables all the way. For the Apple tables, the issue was that we did not clear the DataOffset field when we reached the end, which made our iterator compare unequal to the "end" iterator. For the Dwarf5 tables, the problem was that we incremented the CurrentIndex pointer and then used the incremented (possibly invalid) pointer to check whether we have reached the end of the index list. The reason these bugs went undetected is because their only user (dwarfdump) only ever searched for the first match. Besides allowing us to test this fix, changing llvm-dwarfdump --find to display all matches seems like a good improvement (it makes the behavior consistent with the --name option), so I change llvm-dwarfdump to do that. The existing tests would be sufficient to test this fix with the new llvm-dwarfdump behavior, but I add a special test that demonstrates that the tool indeed displays multiple results. The find.test test needed to be tweaked a bit as the tool now does not print the ".debug_info contents" header (also consistent with how --name works). Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D47543 llvm-svn: 333635
* [dwarfdump] Make -c and -p work togetherJonas Devlieghere2018-05-261-0/+309
| | | | | | | | | | | | | When requesting to dump both the parent chain and children, we used to print the DIE more than once because we propagated the dump options to the parent without clearing the respective flags. This commit fixes this oversight and adds a test. rdar://39415292 Differential revision: https://reviews.llvm.org/D47263 llvm-svn: 333350
* Reapply "DWARFVerifier: Check "completeness" of .debug_names section"Pavel Labath2018-05-151-0/+195
| | | | | | | | | This is a resubmit of r331868 (D46583), which was reverted due to failures on the PS4 bot. These have been resolved with r332246/D46748. llvm-svn: 332349
* [DWARF] Rework debug line parsing to use llvm::Error and callbacksJames Henderson2018-05-103-0/+338
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reviewed by: dblaikie, JDevlieghere, espindola Differential Revision: https://reviews.llvm.org/D44560 Summary: The .debug_line parser previously reported errors by printing to stderr and return false. This is not particularly helpful for clients of the library code, as it prevents them from handling the errors in a manner based on the calling context. This change switches to using llvm::Error and callbacks to indicate what problems were detected during parsing, and has updated clients to handle the errors in a location-specific manner. In general, this means that they continue to do the same thing to external users. Below, I have outlined what the known behaviour changes are, relating to this change. There are two levels of "errors" in the new error mechanism, to broadly distinguish between different fail states of the parser, since not every failure will prevent parsing of the unit, or of subsequent unit. Malformed table errors that prevent reading the remainder of the table (reported by returning them) and other minor issues representing problems with parsing that do not prevent attempting to continue reading the table (reported by calling a specified callback funciton). The only example of this currently is when the last sequence of a unit is unterminated. However, I think it would be good to change the handling of unrecognised opcodes to report as minor issues as well, rather than just printing to the stream if --verbose is used (this would be a subsequent change however). I have substantially extended the DwarfGenerator to be able to handle custom-crafted .debug_line sections, allowing for comprehensive unit-testing of the parser code. For now, I am just adding unit tests to cover the basic error reporting, and positive cases, and do not currently intend to test every part of the parser, although the framework should be sufficient to do so at a later point. Known behaviour changes: - The dump function in DWARFContext now does not attempt to read subsequent tables when searching for a specific offset, if the unit length field of a table before the specified offset is a reserved value. - getOrParseLineTable now returns a useful Error if an invalid offset is encountered, rather than simply a nullptr. - The parse functions no longer use `WithColor::warning` directly to report errors, allowing LLD to call its own warning function. - The existing parse error messages have been updated to not specifically include "warning" in their message, allowing consumers to determine what severity the problem is. - If the line table version field appears to have a value less than 2, an informative error is returned, instead of just false. - If the line table unit length field uses a reserved value, an informative error is returned, instead of just false. - Dumping of .debug_line.dwo sections is now implemented the same as regular .debug_line sections. - Verbose dumping of .debug_line[.dwo] sections now prints the prologue, if there is a prologue error, just like non-verbose dumping. As a helper for the generator code, I have re-added emitInt64 to the AsmPrinter code. This previously existed, but was removed way back in r100296, presumably because it was dead at the time. This change also requires a change to LLD, which will be committed separately. llvm-svn: 331971
* Revert "DWARFVerifier: Check "completeness" of .debug_names section"Pavel Labath2018-05-091-195/+0
| | | | | | | | | | | | | | The new verifier check has found an error in the debug-names-name-collisions.ll test on the PS4 bot: error: Name Index @ 0x0: Entry @ 0xdc: mismatched Name of DIE @ 0x23: index - _ZN3foo3fooE; debug_info - foo. Reverting while I investigate whether this is a bug in the verifier or the generator. This reverts commit r331868. llvm-svn: 331869
* DWARFVerifier: Check "completeness" of .debug_names sectionPavel Labath2018-05-091-0/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a check which makes sure all entries required by the DWARF v5 specification are present in the Name Index. The algorithm tries to follow the wording of Section 6.1.1.1 of the spec as closely as possible. The main deviation from it is that instead of a whitelist-based approach in the spec "The name index must contain an entry for each debugging information entry that defines a named subprogram, label, variable, type, or namespace" I chose a blacklist-based one, where I consider everything to be "in" and then remove the entries that don't make sense. I did this because it has more potential for catching interesting cases and the above is a bit vague (it uses plain words like "variable" and "subprogram", but the rest of the section speaks about specific TAGs). This approach has raised some interesting questions, the main one being whether enumerator values should be indexed. The consensus seems to be that they should, although it does not follow from section 6.1.1.1. For the time being I made the verifier ignore these, as LLVM does not do this yet, and I wanted to get a clean run when verifying generated debug info. Another interesting case was the DW_TAG_imported_declaration. It was not immediately clear to me whether this should go in or not, but currently it is not indexed, and (unlike the enumerators) in does not seem to cause problems for LLDB, so I've also ignored it. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46583 llvm-svn: 331868
OpenPOWER on IntegriCloud