summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
* [Symbolize] Use the local MSVC C++ demangler instead of relying on dbghelp. NFC.Martin Storsjo2019-10-161-25/+11
| | | | | | | | | This allows making a couple llvm-symbolizer tests run in all environments. Differential Revision: https://reviews.llvm.org/D68133 llvm-svn: 375041
* DebugInfo: Remove unnecessary/mistaken inclusion of Bitcode/BitcodeAnalyzer.hDavid Blaikie2019-10-142-4/+0
| | | | | | | | | | | | | | | | Introduced in r374582, Michael Spencer pointed out this broke the modules build due to a missing tblgen dependency on llvm/IR/Attributes.inc. Michael fixed the dependency in r374827. So this removes the inclusion and the new dependency (effectively reverting r374827 and including the alternative fix of removing rather than supporting the new dependency). Thanks for the quick fix/notice, Michael! llvm-svn: 374831
* [Modules Build] Add missing dependency.Michael J. Spencer2019-10-141-0/+3
| | | | | | A previous commit made libLLVMDebugInfoDWARF depend on the LLVM_Bitcode module which depends on the LLVM_intrinsic_gen module which depends on "llvm/IR/Attributes.inc" which is a generated header not depended on by libLLVMDebugInfo. Add that dependency. llvm-svn: 374827
* DebugInfo: Fix msan use-of-uninitialized exposed by r374600David Blaikie2019-10-121-0/+1
| | | | llvm-svn: 374619
* llvm-dwarfdump: Add verbose printing for debug_loclistsDavid Blaikie2019-10-113-39/+111
| | | | llvm-svn: 374582
* [PDB] Fix bug when using multiple PCH header objects with the same name.Zachary Turner2019-10-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | A common pattern in Windows is to have all your precompiled headers use an object named stdafx.obj. If you've got a project with many different static libs, you might use a separate PCH for each one of these. During the final link step, a file from A might reference the PCH object from A, but it will have the same name (stdafx.obj) as any other PCH from another project. The only difference will be the path. For example, A might be A/stdafx.obj while B is B/stdafx.obj. The existing algorithm checks only the filename that was passed on the command line (or stored in archive), but this is insufficient in the case where relative paths are used, because depending on the command line object file / library order, it might find the wrong PCH object first resulting in a signature mismatch. The fix here is to simply check whether the absolute path of the PCH object (which is stored in the input obj file for the file that references the PCH) *ends with* the full relative path of whatever is specified on the command line (or is in the archive). Differential Revision: https://reviews.llvm.org/D66431 llvm-svn: 374442
* Fix Windows build after r374381Nico Weber2019-10-102-7/+2
| | | | llvm-svn: 374413
* Remove strings.h include to fix GSYM Windows buildReid Kleckner2019-10-101-1/+0
| | | | | | Fifth time's the charm. llvm-svn: 374411
* Unbreak buildbots.Greg Clayton2019-10-101-1/+0
| | | | llvm-svn: 374410
* Fix buildbots by using memset instead of bzero.Greg Clayton2019-10-101-1/+1
| | | | llvm-svn: 374409
* Fix build by adding the missing dependency.Michael Liao2019-10-101-1/+1
| | | | llvm-svn: 374406
* Unbreak llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast buildbot.Greg Clayton2019-10-101-1/+1
| | | | llvm-svn: 374398
* Unbreak windows buildbots.Greg Clayton2019-10-101-1/+0
| | | | llvm-svn: 374396
* Add GsymCreator and GsymReader.Greg Clayton2019-10-105-14/+565
| | | | | | | | | | This patch adds the ability to create GSYM files with GsymCreator, and read them with GsymReader. Full testing has been added for both new classes. This patch differs from the original patch https://reviews.llvm.org/D53379 in that is uses a StringTableBuilder class from llvm instead of a custom version. Support for big and little endian files has been added. If the endianness matches the current host, we use efficient extraction for the header, address table and address info offset tables. Differential Revision: https://reviews.llvm.org/D68744 llvm-svn: 374381
* llvm-dwarfdump: Support multiple debug_loclists contributionsDavid Blaikie2019-10-092-15/+18
| | | | | | | Also fixing the incorrect "offset" field being computed/printed for each location list. llvm-svn: 374232
* DebugInfo: Shot in the dark attempt to fix ubsan error from r374122David Blaikie2019-10-091-1/+1
| | | | | | | | (specifying an underlying type for the enum might also be suitable - but this seems better/as good, since there's a clear expectation this can contain values other than the actual enumerators of this enum) llvm-svn: 374196
* Unify the two CRC implementationsHans Wennborg2019-10-094-11/+7
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* DebugInfo: Move LLE enum handling to .def to match RLE handlingDavid Blaikie2019-10-081-1/+1
| | | | llvm-svn: 374122
* Revert "[Symbolize] Use the local MSVC C++ demangler instead of relying on ↵Martin Storsjo2019-10-041-4/+37
| | | | | | | | | dbghelp. NFC." This reverts SVN r373698, as it broke sanitizer tests, e.g. in http://lab.llvm.org:8011/builders/sanitizer-windows/builds/52441. llvm-svn: 373701
* [Symbolize] Use the local MSVC C++ demangler instead of relying on dbghelp. NFC.Martin Storsjo2019-10-041-37/+4
| | | | | | | | | This allows making a couple llvm-symbolizer tests run in all environments. Differential Revision: https://reviews.llvm.org/D68133 llvm-svn: 373698
* DebugInfo: Add parsing support for debug_loc base address specifiersDavid Blaikie2019-10-011-3/+7
| | | | llvm-svn: 373278
* MCRegisterInfo: Merge getLLVMRegNum and getLLVMRegNumFromEHPavel Labath2019-09-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The functions different in two ways: - getLLVMRegNum could return both "eh" and "other" dwarf register numbers, while getLLVMRegNumFromEH only returned the "eh" number. - getLLVMRegNum asserted if the register was not found, while the second function returned -1. The second distinction was pretty important, but it was very hard to infer that from the function name. Aditionally, for the use case of dumping dwarf expressions, we needed a function which can work with both kinds of number, but does not assert. This patch solves both of these issues by merging the two functions into one, returning an Optional<unsigned> value. While the same thing could be achieved by adding an "IsEH" argument to the (renamed) getLLVMRegNumFromEH function, it seemed better to avoid the confusion of two functions and put the choice of asserting into the hands of the caller -- if he checks the Optional value, he can safely process "untrusted" input, and if he blindly dereferences the Optional, he gets the assertion. I've updated all call sites to the new API, choosing between the two options according to the function they were calling originally, except that I've updated the usage in DWARFExpression.cpp to use the "safe" method instead, and added a test case which would have previously triggered an assertion failure when processing (incorrect?) dwarf expressions. Reviewers: dsanders, arsenm, JDevlieghere Subscribers: wdng, aprantl, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67154 llvm-svn: 372710
* [Object] Extend MachOUniversalBinary::getObjectForArchAlexander Shaposhnikov2019-09-191-1/+1
| | | | | | | | | | | | Make the method MachOUniversalBinary::getObjectForArch return MachOUniversalBinary::ObjectForArch and add helper methods MachOUniversalBinary::getMachOObjectForArch, MachOUniversalBinary::getArchiveForArch for those who explicitly expect to get a MachOObjectFile or an Archive. Differential revision: https://reviews.llvm.org/D67700 Test plan: make check-all llvm-svn: 372278
* GSYM: Add the llvm::gsym::Header header class with testsGreg Clayton2019-09-172-0/+112
| | | | | | | | This patch adds the llvm::gsym::Header class which appears at the start of a stand alone GSYM file, or in the first bytes of the GSYM data in a GSYM section within a file. Added encode and decode methods with full error handling and full tests. Differential Revision: https://reviews.llvm.org/D67666 llvm-svn: 372149
* GSYM: add encoding and decoding to FunctionInfoGreg Clayton2019-09-171-4/+132
| | | | | | | | This patch adds encoding and decoding of the FunctionInfo objects along with full error handling and tests. Full details of the FunctionInfo encoding format appear in the FunctionInfo.h header file. Differential Revision: https://reviews.llvm.org/D67506 llvm-svn: 372135
* [DebugInfo] Don't dereference a dyn_cast<PDBSymbolData> result. NFCI.Simon Pilgrim2019-09-151-1/+1
| | | | | | The static analyzer is warning about a potential null dereference - but as we're in DataMemberLayoutItem we should be able to guarantee that the Symbol is a PDBSymbolData type, allowing us to use cast<PDBSymbolData> - and if not assert will fire for us. llvm-svn: 371933
* Add some missing changes to GSYM that was addressing a gcc compilation error ↵David Blaikie2019-09-111-1/+1
| | | | | | due to a type and variable with the same name llvm-svn: 371681
* Add a LineTable class to GSYM and test it.Greg Clayton2019-09-113-4/+289
| | | | | | | | | | This patch adds the ability to create a gsym::LineTable object, populate it, encode and decode it and test all functionality. The full format of the LineTable encoding is specified in the header file LineTable.h. Differential Revision: https://reviews.llvm.org/D66602 llvm-svn: 371657
* [GSYM][NFC] Fixed -Wdocumentation warningDavid Bolvansky2019-09-051-1/+0
| | | | | | lib/DebugInfo/GSYM/InlineInfo.cpp:68:12: warning: parameter 'Inline' not found in the function declaration [-Wdocumentation] llvm-svn: 371125
* [DWARF] Fix referencing Range List Tables from CUs for DWARF64.Igor Kudrin2019-09-051-9/+12
| | | | | | | | | | | | | | As DW_AT_rnglists_base points after the header and headers have different sizes for DWARF32 and DWARF64, we have to use the format of the CU to adjust the offset correctly in order to extract the referenced range list table. The patch also changes the type of RangeSectionBase because in DWARF64 it is 8-bytes long. Differential Revision: https://reviews.llvm.org/D67098 llvm-svn: 371016
* [DWARF] Support DWARF64 in DWARFListTableHeader.Igor Kudrin2019-09-051-22/+30
| | | | | | | | This enables 64-bit DWARF support for parsing range and location list tables. Differential Revision: https://reviews.llvm.org/D66643 llvm-svn: 371014
* Add encode and decode methods to InlineInfo and document encoding format to ↵Greg Clayton2019-09-042-0/+112
| | | | | | | | | | the GSYM file format. This patch adds the ability to encode and decode InlineInfo objects and adds test coverage. Error handling is introduced in the encoding and decoding which will be used from here on out for remaining patches. Differential Revision: https://reviews.llvm.org/D66600 llvm-svn: 370936
* DWARF: Fix a regression in location list dumpingPavel Labath2019-09-042-26/+22
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: While fixing the handling of some error cases, r370363 introduced new problems -- assertion failures due to unchecked errors (my excuse is that a very early version of that patch used Optional<T> instead of Expected). This patch adds proper handling of parsing errors encountered when dumping location lists from inside DWARF DIEs, and adds a bunch of additional tests. I reorder the arguments of the location list dumping functions to make them consistent, and also be able to dump the two kinds of location lists generically. Reviewers: JDevlieghere, dblaikie, probinson Subscribers: aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67102 llvm-svn: 370868
* [DWARFVerifier] Verify GNU extensions of call site DWARF symbolsDjordje Todorovic2019-09-021-2/+7
| | | | | | | | | Verify that the call site DWARF symbols (added during the implementation of the debug entry values feature) are generated properly. Differential Revision: https://reviews.llvm.org/D66865 llvm-svn: 370631
* DWARFDebugLoc: Make parsing and error reporting more robustPavel Labath2019-08-292-60/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
* Add error handling to the DataExtractor classPavel Labath2019-08-271-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is motivated by D63591, where we realized that there isn't a really good way of telling whether a DataExtractor is reading actual data, or is it just returning default values because it reached the end of the buffer. This patch resolves that by providing a new "Cursor" class. A Cursor object encapsulates two things: - the current position/offset in the DataExtractor - an error object Storing the error object inside the Cursor enables one to use the same pattern as the std::{io}stream API, where one can blindly perform a sequence of reads and only check for errors once at the end of the operation. Similarly to the stream API, as soon as we encounter one error, all of the subsequent operations are skipped (return default values) too, even if the would suceed with clear error state. Unlike the std::stream API (but in line with other llvm APIs), we force the error state to be checked through usage of llvm::Error. Reviewers: probinson, dblaikie, JDevlieghere, aprantl, echristo Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63713 llvm-svn: 370042
* Removing block comments from CodeView records in assembly files & related ↵Nilanjana Basu2019-08-251-15/+0
| | | | | | code cleanup llvm-svn: 369860
* Add FileWriter to GSYM and encode/decode functions to AddressRange and ↵Greg Clayton2019-08-213-0/+115
| | | | | | | | | | | | | | | | AddressRanges The full GSYM patch started with: https://reviews.llvm.org/D53379 This patch add the ability to encode data using the new llvm::gsym::FileWriter class. FileWriter is a simplified binary data writer class that doesn't require targets, target definitions, architectures, or require any other optional compile time libraries to be enabled via the build process. This class needs the ability to seek to different spots in the binary data that it produces to fix up offsets and sizes in GSYM data. It currently uses std::ostream over llvm::raw_ostream because llvm::raw_ostream doesn't support seeking which is required when encoding and decoding GSYM data. AddressRange objects are encoded and decoded to be relative to a base address. This will be the FunctionInfo's start address if the AddressRange is directly contained in a FunctionInfo, or a base address of the containing parent AddressRange or AddressRanges. This allows address ranges to be efficiently encoded using ULEB128 encodings as we encode the offset and size of each range instead of full addresses. This also makes encoded addresses easy to relocate as we just need to relocate one base address. Differential Revision: https://reviews.llvm.org/D63828 llvm-svn: 369587
* Improving CodeView debug info type record's inline commentsNilanjana Basu2019-08-213-35/+380
| | | | llvm-svn: 369533
* [DWARF] Adjust return type of DWARFUnit::getLength().Igor Kudrin2019-08-212-3/+3
| | | | | | | | | DWARFUnitHeader::getLength() returns uint64_t. DWARFUnit::getLength() should do the same. Differential Revision: https://reviews.llvm.org/D66472 llvm-svn: 369529
* [DWARF] Fix reading 64-bit DWARF type units.Igor Kudrin2019-08-202-5/+5
| | | | | | | | | | The type_offset field is 8 bytes long in DWARF64. The patch extends TypeOffset to uint64_t and fixes its reading. The patch also fixes checking of TypeOffset bounds as it was inaccurate in DWARF64 case. Differential Revision: https://reviews.llvm.org/D66465 llvm-svn: 369378
* Remove the temporary code. NFC.Igor Kudrin2019-08-161-30/+0
| | | | | | That should have been done in rL368156 but somehow was missed. llvm-svn: 369082
* [DebugLine] Don't try to guess the path styleJonas Devlieghere2019-08-151-25/+5
| | | | | | | | | | | In r368879 I made an attempt to guess the path style from the files in the line table. After some consideration I now think this is a poor idea. This patch undoes that behavior and instead adds an optional argument to specify the path style. This allows us to make that decision elsewhere where we have more information. In case of LLDB based on the Unit. llvm-svn: 369072
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1524-106/+106
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [llvm-objdump] Add warning messages if disassembly + source for problematic ↵Michael Pozulp2019-08-152-12/+7
| | | | | | | | | | | | | | | | | | inputs Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905 Reviewers: jhenderson, rupprecht, grimar Reviewed By: jhenderson, grimar Subscribers: RKSimon, MaskRay, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62462 llvm-svn: 368963
* [DebugLine] Improve path handling.Jonas Devlieghere2019-08-141-2/+20
| | | | | | | | | | | | | | | | | After switching over LLDB's line table parser to libDebugInfo, we noticed two regressions on the Windows bot. The problem is that when obtaining a file from the line table prologue, we append paths without specifying a path style. This leads to incorrect results on Windows for debug info containing Posix paths: 0x0000000000201000: /tmp\b.c, is_start_of_statement = TRUE This patch is an attempt to fix that by guessing the path style whenever possible. Differential revision: https://reviews.llvm.org/D66227 llvm-svn: 368879
* Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-143-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
* Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-143-20/+8
| | | | | | | | Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
* [llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar2019-08-143-8/+20
| | | | | | | | | | | | | | | | | | | | | | | SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
* DebugInfo/DWARF: Provide some (pretty half-hearted) error handling access ↵David Blaikie2019-08-091-17/+25
| | | | | | | | | | | | | | | | | | | | | | when parsing units This isn't the most robust error handling API, but does allow clients to opt-in to getting Errors they can handle. I suspect the long-term solution would be to move away from the lazy unit parsing and have an explicit step that parses the unit and then allows access to the other APIs that require a parsed unit. llvm-dwarfdump could be expanded to use this (or newer/better API) to demonstrate the benefit of it - but for now lld will use this in a follow-up cl which ensures lld can exit non-zero on errors like this (& provide more descriptive diagnostics including which object file the error came from). (error access to later errors when parsing nested DIEs would be good too - but, again, exposing that without it being a hassle for every consumer may be tricky) llvm-svn: 368377
OpenPOWER on IntegriCloud