summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
* [DWARF] Support for .debug_addr (consumer)Victor Leschuk2018-07-313-10/+252
| | | | | | | This patch implements basic support for parsing and dumping DWARFv5 .debug_addr section. llvm-svn: 338447
* [CodeView] Minimal support for S_UNAMESPACE recordsAlexandre Ganea2018-07-314-1/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D50007 llvm-svn: 338417
* This fixes a crash when a second pass is required for the Codeview Type ↵Alexandre Ganea2018-07-301-1/+4
| | | | | | | | | | merging *and* the index points outside of the table (which should lead to an error being printed). This occurs currently until MS precompiled headers .obj is added (see D45213) Differential Revision: https://reviews.llvm.org/D50006 llvm-svn: 338308
* Remove trailing spaceFangrui Song2018-07-303-3/+3
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [DWARF v5] Don't report an error when the .debug_rnglists section is empty ↵Wolfgang Pieb2018-07-261-16/+18
| | | | | | | | | | | or non-existent. Fixes PR38297. Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D49815 llvm-svn: 337993
* [DWARF] Use deque in place of SmallVector to fix use-after-free issueFangrui Song2018-07-231-3/+6
| | | | | | | | | | | | Summary: SmallVector's elements are moved when resizing and cause use-after-free. Reviewers: probinson, dblaikie Subscribers: JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D49702 llvm-svn: 337772
* Embed a template specialization in a namespace to work around a gcc bug.Wolfgang Pieb2018-07-231-0/+2
| | | | llvm-svn: 337770
* [DWARF v5] Refactor range lists dumping by using a more generic way of ↵Wolfgang Pieb2018-07-234-190/+132
| | | | | | | | | | | | | 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
* [llvm] Change 2 instances of std::sort to llvm::sortMandeep Singh Grang2018-07-161-1/+1
| | | | llvm-svn: 337192
* [dwarfdump] Add pretty printer for accelerator table based on Atom.Jonas Devlieghere2018-07-131-3/+9
| | | | | | | | For instance, When dumping .apple_types, the second atom represents the DW_TAG. In addition to printing the raw value, we now also pretty print the value if the ATOM tells us how. llvm-svn: 337026
* [DebugInfo] Fix getPreviousSibling after r336823Fangrui Song2018-07-111-1/+2
| | | | llvm-svn: 336837
* [DebugInfo] Make children iterator bidirectionalJonas Devlieghere2018-07-112-0/+45
| | | | | | | | | Make the DIE iterator bidirectional so we can move to the previous sibling of a DIE. Differential revision: https://reviews.llvm.org/D49173 llvm-svn: 336823
* Use StringRef instead of `const char *`.Rui Ueyama2018-07-091-1/+1
| | | | | | | | | | I don't think there's a need to use `const char *`. In most (probably all?) cases, we need a length of a name later, so discarding a length will lead to a wasted effort. Differential Revision: https://reviews.llvm.org/D49046 llvm-svn: 336612
* [DebugInfo] Change default value of FDEPointerEncodingMaksim Panchenko2018-07-091-1/+1
| | | | | | | | | | | | | | | | Summary: If the encoding is not specified in CIE augmentation string, then it should be DW_EH_PE_absptr instead of DW_EH_PE_omit. Reviewers: ruiu, MaskRay, plotfi, rafauler Reviewed By: MaskRay Subscribers: rafauler, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D49000 llvm-svn: 336577
* [PDB] memicmp only exists on Windows, use StringRef::compare_lower insteadBenjamin Kramer2018-07-061-2/+2
| | | | llvm-svn: 336469
* [PDB] One more fix for hasing GSI records.Zachary Turner2018-07-061-8/+27
| | | | | | | | | | | | | | | | The reference implementation uses a case-insensitive string comparison for strings of equal length. This will cause the string "tEo" to compare less than "VUo". However we were using a case sensitive comparison, which would generate the opposite outcome. Switch to a case insensitive comparison. Also, when one of the strings contains non-ascii characters, fallback to a straight memcmp. The only way to really test this is with a DIA test. Before this patch, the test will fail (but succeed if link.exe is used instead of lld-link). After the patch, it succeeds even with lld-link. llvm-svn: 336464
* [PDB] Sort globals symbols by name in GSI hash buckets.Zachary Turner2018-07-061-5/+19
| | | | | | | | | | | It seems like the debugger first computes a symbol's bucket, and then does a binary search of entries in the bucket using the symbol's name in order to find it. If the bucket entries are not in sorted order, this obviously won't work. After this patch a couple of simple test cases show that we generate an exactly identical GSI hash stream, which is very nice. llvm-svn: 336405
* [CodeView] Correctly compute the name of S_PROCREF symbols.Zachary Turner2018-06-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a function which switches on the type of a symbol record to return a hardcoded offset into the record that contains the symbol name. Not all symbols have names to begin with, and for those records we return -1 for the offset. Names are used for various things. Importantly for this particular bug, a hash of the record name is used as a key for certain hash tables which are serialied into the PDB file. One of these hash tables is for the global symbol stream, which is basically a collection of S_PROCREF symbols which contain the name of the symbol, a module, and an address offset. However, for S_PROCREF symbols, the function to return the offset of the name was returning -1: basically it wasn't implemented. As a result of this, all global symbols were hashing to the same value, essentially it was as if every single global symbol's name was the empty string. This manifests in the VS debugger when you try to call a function (global or member, doesn't matter) through the immediate window and the debugger simply reports an error because it can't find the function. This makes perfect sense, because it is hashing the name for real, looking in the global symbol hash table, and there is only 1 entry there which corresponds to a symbol whose name is the empty string. Fixing this fixes the MSVC debugger in this case. llvm-svn: 336024
* Pass DWARFUnit to verifier by reference not by value. I am moderatelyPaul Robinson2018-06-291-1/+1
| | | | | | sure this should not cause a memory leak. llvm-svn: 336007
* Move some code from PDBFileBuilder to MSFBuilder.Zachary Turner2018-06-272-73/+91
| | | | | | | | The code to emit the pieces of the MSF file were actually in PDBFileBuilder. Move this to MSFBuilder so that we can theoretically emit an MSF without having a PDB file. llvm-svn: 335789
* Handle NetBSD specific path in findDebugBinary()Kamil Rytarowski2018-06-251-0/+5
| | | | | | | | | | | | | | | | | | | | Summary: The NetBSD Operating System installs debuginfo files into /usr/libdata/debug, rather than other path like in some other popular distribution. This change makes llvm-symbolizer functional with the basesystem executables. Reviewers: joerg, vitalybuka Reviewed By: vitalybuka Subscribers: JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D48525 llvm-svn: 335511
* [DWARF] Improved error reporting for range lists. Wolfgang Pieb2018-06-206-51/+108
| | | | | | | | | | | Errors found processing the DW_AT_ranges attribute are propagated by lower level routines and reported by their callers. Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D48344 llvm-svn: 335188
* [DWARF/AccelTable] Remove getDIESectionOffset for DWARF v5 entriesPavel Labath2018-06-132-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add an iterator-based api for accessing names in the ↵Pavel Labath2018-06-012-37/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | index Summary: Back when we were introducing the DWARF v5 name index, there was a short discussion whether we shouldn't have a nicer api for iterating over the index. At that time, I did not find it necessary since the iteration over names was done only from within the index itself (and I figured the internal implementation can deal with a slightly rough interface). However, now I ran into a use for this kind of API in LLDB (for finding all names matching a regular expression), so it looked like a nice opportunity to introduce one. To make the API more useful, I've made the NameTableEntry class a bit smarter: it now stores the string section reference (so it can return its name) and its position in the name index (mainly useful for dumping/logging). I also convert the internal users to use the new API, which also gives test coverage for the added code. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47590 llvm-svn: 333738
* DWARFAcceleratorTable: fix equal_range iteratorsPavel Labath2018-05-311-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeView] Add prefix to CodeView registers.Jonas Devlieghere2018-05-291-2/+2
| | | | | | | | | | | | | Adds CVReg to CodeView register names to prevent a duplicate symbol with CR3 defined in termios.h, as suggested by Zachary on the mailing list. http://lists.llvm.org/pipermail/llvm-dev/2018-May/123372.html Differential revision: https://reviews.llvm.org/D47478 rdar://39863705 llvm-svn: 333421
* [dwarfdump] Make -c and -p work togetherJonas Devlieghere2018-05-261-3/+7
| | | | | | | | | | | | | 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
* [DebugInfo] Invert DIE order for range errors.Jonas Devlieghere2018-05-221-3/+2
| | | | | | | | | When printing an error for an invalid address range in a DIE, we used to print the child above the parent, which is counter intuitive. This patch reverses the order and indents the child to mimic the way we print the debug info section. llvm-svn: 333006
* [DebugInfo] Fix location list check in the verifierJonas Devlieghere2018-05-221-4/+4
| | | | | | | We weren't properly verifying location lists because we tried obtaining the offset as a constant. llvm-svn: 333005
* [DWARFv5] Put the DWO ID in its place.Paul Robinson2018-05-223-14/+30
| | | | | | | | | | | | In DWARF v5, the DWO ID is in the (split/skeleton) CU header, not an attribute on the CU DIE. This changes the size of those headers, so use the parsed size whenever we have one, for simplicitly. Differential Revision: https://reviews.llvm.org/D47158 llvm-svn: 333004
* [DebugInfo] Use absolute addresses in location listsJonas Devlieghere2018-05-213-11/+24
| | | | | | | | | | | Rather than relying on the user to do the address calculating in DW_AT_location we should just dump the absolute address. rdar://problem/38513870 Differential revision: https://reviews.llvm.org/D47152 llvm-svn: 332873
* [DWARF] Refactor callback usage for .debug_line error handlingJames Henderson2018-05-212-24/+26
| | | | | | | | | | | Change the "recoverable" error callback to take an Error instaed of a string. Reviewed by: JDevlieghere Differential Revision: https://reviews.llvm.org/D46831 llvm-svn: 332845
* Fixing buildbot error introduced with r332759.Wolfgang Pieb2018-05-181-1/+1
| | | | llvm-svn: 332772
* Addressing a couple of compiler warnings introduced with r332759.Wolfgang Pieb2018-05-181-2/+2
| | | | llvm-svn: 332766
* Fixing build error introduced with r332759.Wolfgang Pieb2018-05-181-1/+1
| | | | llvm-svn: 332762
* [DWARF v5] Improved support for .debug_rnglists (consumer). Enables any ↵Wolfgang Pieb2018-05-185-30/+214
| | | | | | | | | | | | consumer to extract DWARF v5 encoded rangelists. Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D45549 llvm-svn: 332759
* Resubmit [pdb] Change /DEBUG:GHASH to emit 8 byte hashes."Zachary Turner2018-05-171-5/+5
| | | | | | | This fixes the remaining failing tests, so resubmitting with no functional change. llvm-svn: 332676
* Revert "[pdb] Change /DEBUG:GHASH to emit 8 byte hashes."Zachary Turner2018-05-171-4/+5
| | | | | | | A few tests haven't been properly updated, so reverting while I have time to investigate proper fixes. llvm-svn: 332672
* [pdb] Change /DEBUG:GHASH to emit 8 byte hashes.Zachary Turner2018-05-171-5/+4
| | | | | | | | | | | | | | | | Previously we emitted 20-byte SHA1 hashes. This is overkill for identifying debug info records, and has the negative side effect of making object files bigger and links slower. By using only the last 8 bytes of a SHA1, we get smaller object files and ~10% faster links. This modifies the format of the .debug$H section by adding a new value for the hash algorithm field, so that the linker will still work when its object files have an old format. Differential Revision: https://reviews.llvm.org/D46855 llvm-svn: 332669
* [codeview] Include record prefix in global type hashingReid Kleckner2018-05-171-0/+1
| | | | | | | | | | | | The prefix includes type kind, which is important to preserve. Two different type leafs can easily have the same interior record contents as another type. We ran into this issue in PR37492 where a bitfield type record collided with a const modifier record. Their contents were bitwise identical, but their kinds were different. llvm-svn: 332664
* Reapply "DWARFVerifier: Check "completeness" of .debug_names section"Pavel Labath2018-05-152-2/+176
| | | | | | | | | 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] Factor out a DWARFUnitHeader class. NFCPaul Robinson2018-05-143-56/+44
| | | | | | | | | | | Extract information related to a "unit header" from DWARFUnit into a new DWARFUnitHeader class, and add a DWARFUnit member for the header. This is one step in the direction of allowing type units in the .debug_info section for DWARF v5. Differential Revision: https://reviews.llvm.org/D46707 llvm-svn: 332289
* [CodeGen/AccelTable]: Handle -dwarf-linkage-names=Abstract correctlyPavel Labath2018-05-141-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: If we are not emitting a linkage name in the .debug_info sections, we should not add it into the index either. This makes sure our index is consistent with the actual debug info. I am also explicitly setting the --dwarf-linkage-names=All in the name-collsions test as that one would now fail on targets where this defaults to "Abstract" (in fact, it would have failed already if there wasn't a bug in the DWARF verifier, which I fix as well). Reviewers: probinson, aprantl, JDevlieghere Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46748 llvm-svn: 332246
* [DWARF] Fixing a bug in DWARF v5 string offsets tables where the length ↵Wolfgang Pieb2018-05-102-3/+12
| | | | | | | | | | | | | encoded the contribution length excluding the table header. Instead it must encode the contribution length minus the length field itself. Reviewer: JDevliegehere Differential Revision: https://reviews.llvm.org/D45922 llvm-svn: 332030
* Fix signed/unsigned comparison warning and print formatJames Henderson2018-05-101-1/+1
| | | | | | | | | | | | The print format was causing at least 2 unit-test failures from r331971. The signed/unsigned comparison warnings only appeared to affect two lines but it was unclear whether it might just pop up on other lines, so I have been explicit in all the literals in the tests. There were other bot unit-test failures that I am still investigating. llvm-svn: 331978
* [DWARF] Rework debug line parsing to use llvm::Error and callbacksJames Henderson2018-05-102-122/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-092-177/+2
| | | | | | | | | | | | | | 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-092-2/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [DebugInfo] Accept `S` in augmentation strings in CIE.Fangrui Song2018-05-081-0/+3
| | | | | | glibc libc.a(sigaction.o) compiled from sysdeps/unix/sysv/linux/x86_64/sigaction.c uses "zRS". llvm-svn: 331738
* llvm-symbolizer: Handle function definitions nested within other functionsDavid Blaikie2018-05-011-2/+6
| | | | | | | | | | | | LLVM always puts function definition DIEs at the top level, but under some circumstances GCC does not (at least in this case with member functions of a function-local type). To ensure that doesn't appear as though the local type's member function is unduly inlined within the outer function - ensure the inline discovery DIE parent walk stops at the first DW_TAG_subprogram. llvm-svn: 331291
OpenPOWER on IntegriCloud