summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* [DWARF] Add an api to get "interpreted" location listsPavel Labath2019-11-203-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds DWARFDie::getLocations, which returns the location expressions for a given attribute (typically DW_AT_location). It handles both "inline" locations and references to the external location list sections (currently only of the DW_FORM_sec_offset type). It is implemented on top of DWARFUnit::findLoclistFromOffset, which is also added in this patch. I tried to make their signatures similar to the equivalent range list functionality. The actual location list interpretation logic is in DWARFLocationTable::visitAbsoluteLocationList. This part is not equivalent to the range list code, but this deviation is motivated by a desire to reuse the same location list parsing code within lldb. The functionality is tested via a c++ unit test of the DWARFDie API. Reviewers: dblaikie, JDevlieghere, SouraVX Subscribers: mgorny, hiraditya, cmtice, probinson, llvm-commits, aprantl Tags: #llvm Differential Revision: https://reviews.llvm.org/D70394
* Add streaming/equality operators to DWARFAddressRange/DWARFLocationExpressionPavel Labath2019-11-192-0/+20
| | | | | | | The main motivation for this is being able to write simpler assertions and get better error messages in unit tests. Split off from D70394.
* Re-commit "DWARF location lists: Add section index dumping"Pavel Labath2019-11-184-20/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies c0f6ad7d1f3ccb9d0b9ce9ef8dfa06409ccf1b3e with an additional fix in test/DebugInfo/X86/constant-loclist.ll, which had a slightly different output on windows targets. The test now accounts for this difference. The original commit message follows. Summary: As discussed in D70081, this adds the ability to dump section names/indices to the location list dumper. It does this by moving the range specific logic from DWARFDie.cpp:dumpRanges into the DWARFAddressRange class. The trickiest part of this patch is the backflip in the meanings of the two dump flags for the location list sections. The dumping of "raw" location list data is now controlled by "DisplayRawContents" flag. This frees up the "Verbose" flag to be used to control whether we print the section index. Additionally, the DisplayRawContents flag is set for section-based dumps whenever the --verbose option is passed, but this is not done for the "inline" dumps. Also note that the index dumping currently does not work for the DWARF v5 location lists, as the parser does not fill out the appropriate fields. This will be done in a separate patch. Reviewers: dblaikie, probinson, JDevlieghere, SouraVX Subscribers: sdardis, hiraditya, jrtc27, atanasyan, arphaman, aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70227
* Revert rGc0f6ad7d1f3c : "DWARF location lists: Add section index dumping"Simon Pilgrim2019-11-184-26/+20
| | | | This reverts commit c0f6ad7d1f3ccb9d0b9ce9ef8dfa06409ccf1b3e to fix the buildbots.
* DWARF location lists: Add section index dumpingPavel Labath2019-11-184-20/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in D70081, this adds the ability to dump section names/indices to the location list dumper. It does this by moving the range specific logic from DWARFDie.cpp:dumpRanges into the DWARFAddressRange class. The trickiest part of this patch is the backflip in the meanings of the two dump flags for the location list sections. The dumping of "raw" location list data is now controlled by "DisplayRawContents" flag. This frees up the "Verbose" flag to be used to control whether we print the section index. Additionally, the DisplayRawContents flag is set for section-based dumps whenever the --verbose option is passed, but this is not done for the "inline" dumps. Also note that the index dumping currently does not work for the DWARF v5 location lists, as the parser does not fill out the appropriate fields. This will be done in a separate patch. Reviewers: dblaikie, probinson, JDevlieghere, SouraVX Subscribers: sdardis, hiraditya, jrtc27, atanasyan, arphaman, aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70227
* DebugInfo: Use loclistx for DWARFv5 location lists to reduce the number of ↵David Blaikie2019-11-153-0/+41
| | | | | | | | | | relocations This only implements the non-dwo part, but loclistx is necessary to use location lists in DWARFv5, so it's a precursor to that work - and generally reduces relocations (only using one reloc, then indexes/relative offsets for all location list references) in non-split DWARF.
* DebugInfo: Templatize rnglist header parsing to setup for reuse with loclist ↵David Blaikie2019-11-151-9/+10
| | | | header parsing
* DWARFDebugLoc(v4): Add an incremental parsing functionPavel Labath2019-11-155-104/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds a visitLocationList function to the DWARF v4 location lists, similar to what already exists for DWARF v5. It follows the approach outlined in previous patches (D69672), where the parsed form is always stored in the DWARF v5 format, which makes it easier for generic code to be built on top of that. v4 location lists are "upgraded" during parsing, and then this upgrade is undone while dumping. Both "inline" and section-based dumping is rewritten to reuse the existing "generic" location list dumper. This means that the output format is consistent for all location lists (the only thing one needs to implement is the function which prints the "raw" form of a location list), and that debug_loc dumping correctly processes base address selection entries, etc. The previous existing debug_loc functionality (e.g., parseOneLocationList) is rewritten on top of the new API, but it is not removed as there is still code which uses them. This will be done in follow-up patches, after I build the API to access the "interpreted" location lists in a generic way (as that is what those users really want). Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69847
* DWARFDebugLoclists: stricter base address handlingPavel Labath2019-11-143-17/+14
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This removes the use of zero as a base address in section-based dumping. Although this will often be true for (unlinked) object files with a single compile unit, it is not true in general. This means that section-based dumping will not be able to resolve entries referencing the base address (DW_LLE_offset_pair) -- it wasn't able to do that correctly before either, but now it will be more explicit about it. One exception to that is if the location list contains an explicit DW_LLE_base_address entry -- in this case the dumper will pick it up, and resolve subsequent entries normally. The patch also removes the fallback to zero in the "inline" dumping in case the compile unit does not contain a base address. Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70115
* DWARFDebugLoclists: Add an api to get the location lists of a DWARF unitPavel Labath2019-11-132-40/+34
| | | | | | | | | | | | | | | | | Summary: This avoid the need to duplicate the location lists searching logic in various users. The "inline location list dumping" code (which is the only user actually updated to handle DWARF v5 location lists) is switched to this method. After adding v4 location list support, I'll switch other users too. Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70084
* DWARFDebugLoclists: add location list "interpretation" logicPavel Labath2019-11-123-110/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch extracts the logic for computing the "absolute" locations, which was partially present in the debug_loclists dumper, completes it, and moves it into a separate function. This makes it possible to later reuse the same logic for uses other than dumping. The dumper is changed to reuse the location list interpreter, and its format is changed somewhat. In "verbose" mode it prints the "raw" value of a location list, the interpreted location (if available) and the expression itself. In non-verbose mode it prints only one of the location forms: it prefers the interpreted form, but falls back to the "raw" format if interpretation is not possible (for instance, because we were not given a base address, or the resolution of indirect addresses failed). This patch also undos some of the changes made in D69672, namely the part about making all functions static. The main reason for this is that I learned that the original approach (dumping only fully resolved locations) meant that it was impossible to rewrite one of the existing tests. To make that possible (and make the "inline location" dump work in more cases), I now reuse the same dumping mechanism as is used for section-based dumping. As this required having more objects know about the various location lists classes, it seemed like a good idea to create an interface abstracting the difference between them. Therefore, I now create a DWARFLocationTable class, which will serve as a base class for the location list classes. DWARFDebugLoclists is made to inherit from that. DWARFDebugLoc will follow. Another positive effect of this change is that section-based dumping code will not need to use templates (as originally) envisioned, and that the argument lists of the dumping functions become shorter. Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70081
* [PDB] Make pdb::DbiModuleDescriptor destructor trivialFangrui Song2019-11-111-2/+0
|
* DebugInfo: Use separate macinfo contributions for each CUDavid Blaikie2019-11-081-35/+41
| | | | | | | | | | | | | | | | The macinfo support was broken for LTO situations, by terminating macinfo lists only once - multiple macinfo contributions were correctly labeled, but they all continued/flowed into later contributions until only one terminator appeared at the end of the section. Correctly terminate each contribution & fix the parsing to handle this situation too. The parsing fix is also necessary for dumping linked binaries - the previous code would stop at the end of the first contribution - missing all later contributions in a linked binary. It'd be nice to improve the dumping to print the offsets of each contribution so it'd be easier to know which CU AT_macro_info refers to which macinfo contribution.
* DWARFDebugLoclists: Move to a incremental parsing modelPavel Labath2019-11-063-123/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch stems from the discussion D68270 (including some offline talks). The idea is to provide an "incremental" api for parsing location lists, which will avoid caching or materializing parsed data. An additional goal is to provide a high level location list api, which abstracts the differences between different encoding schemes, and can be used by users which don't care about those (such as LLDB). This patch implements the first part. It implements a call-back based "visitLocationList" api. This function parses a single location list, calling a user-specified callback for each entry. This is going to be the base api, which other location list functions (right now, just the dumping code) are going to be based on. Future patches will do something similar for the v4 location lists, and add a mechanism to translate raw entries into concrete address ranges. Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69672
* DWARFDebugLoclists: Make it possible to read relocated addressesPavel Labath2019-11-053-15/+17
| | | | | | | | | | | | | | | | | Summary: Handling relocations was not needed when the loclists section was a DWO-only thing. But since DWARF5, it is possible to use it in regular objects too, and the standard permits embedding addresses into the section directly. These addresses need to be relocated in unlinked files. Reviewers: JDevlieghere, dblaikie, probinson Subscribers: aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68271
* Fix -Wsign-compare warning with clang-clReid Kleckner2019-10-301-2/+2
| | | | | | off_t apparently is just "long" on Win64, which is 32-bits, and therefore not long enough to compare with UINT32_MAX. Use auto to follow the surrounding code. uint64_t would also be fine.
* Hide implementation details in anonymous namespaces. NFC.Benjamin Kramer2019-10-241-1/+1
|
* [LLVMDebugInfoPDB] - Use cantFail() instead of assert().George Rimar2019-10-221-12/+13
| | | | | | | | | | | | | | | | Currently injected-sources-native.test fails with "Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed)" when llvm is compiled with LLVM_ENABLE_ABI_BREAKING_CHECKS in Release. The problem is that getStringForID returns Expected<StringRef> and Expected value must always be checked, even if it is in success state. Checking with assert only helps in Debug and is wrong. Differential revision: https://reviews.llvm.org/D69251 llvm-svn: 375492
* [llvm/Object] - Make ELFObjectFile::getRelocatedSection return ↵George Rimar2019-10-211-1/+10
| | | | | | | | | | | | | Expected<section_iterator> It returns just a section_iterator currently and have a report_fatal_error call inside. This change adds a way to return errors and handle them on caller sides. The patch also changes/improves current users and adds test cases. Differential revision: https://reviews.llvm.org/D69167 llvm-svn: 375408
* Fix minor warning in DWARFVerifier.Zinovy Nis2019-10-201-2/+2
| | | | llvm-svn: 375357
* [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
OpenPOWER on IntegriCloud