summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/DWARF
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* 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
* [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
* 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
* 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
* DebugInfo: Move LLE enum handling to .def to match RLE handlingDavid Blaikie2019-10-081-1/+1
| | | | llvm-svn: 374122
* 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
* [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
* 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
* [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-155-16/+16
| | | | | | | | 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-151-1/+1
| | | | | | | | | | | | | | | | | | 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-141-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-141-10/+3
| | | | | | | | 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-141-3/+10
| | | | | | | | | | | | | | | | | | | | | | | 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
* Remove else-after-returnDavid Blaikie2019-08-081-3/+3
| | | | llvm-svn: 368364
* DebugInfo/DWARF: Remove unused return type from DWARFUnit::extractDIEsIfNeededDavid Blaikie2019-08-071-64/+63
| | | | llvm-svn: 368212
* Fix indentationDavid Blaikie2019-08-071-1/+1
| | | | llvm-svn: 368198
* DebugInfo/DWARF: Normalize DWARFObject members on the DWARF spec section namesDavid Blaikie2019-08-074-105/+105
| | | | | | | | | Some of these names were abbreviated, some were not, some pluralised, some not. Made the API difficult to use - since it's an exact 1:1 mapping to the DWARF sections - use those names (changing underscore separation for camel casing). llvm-svn: 368189
* Remove support for 32-bit offsets in utility classes (5/5)Igor Kudrin2019-08-072-47/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D65641 llvm-svn: 368156
* Try to unbreak buildbots after r368014Igor Kudrin2019-08-061-1/+1
| | | | llvm-svn: 368018
* Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin2019-08-0624-292/+302
| | | | | | | | | This updates all libraries and tools in LLVM Core to use 64-bit offsets which directly or indirectly come to DataExtractor. Differential Revision: https://reviews.llvm.org/D65638 llvm-svn: 368014
* Support 64-bit offsets in utility classes (1/5)Igor Kudrin2019-08-062-7/+75
| | | | | | | | | | Using 64-bit offsets is required to fully implement 64-bit DWARF. As these classes are used in many different libraries they should temporarily support both 32- and 64-bit offsets. Differential Revision: https://reviews.llvm.org/D64006 llvm-svn: 368013
* Revert "[llvm-objdump] Re-commit r367284."Michael Pozulp2019-08-051-1/+1
| | | | | | | | This reverts r367776 (git commit d34099926e909390cb0254bebb4b7f5cf15467c7). My changes to llvm-objdump tests caused them to fail on windows: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/27368 llvm-svn: 367816
* [DWARF] Change DWARFDebugLoc::Entry::Loc from SmallVector<char, 4> to ↵Fangrui Song2019-08-051-2/+2
| | | | | | | | | SmallString<4> SmallString has a conversion to StringRef, which can be leveraged to simplify two use sites. llvm-svn: 367801
* [llvm-objdump] Re-commit r367284.Michael Pozulp2019-08-041-1/+1
| | | | | | | | | | | | | | | | | | Add warning messages if disassembly + source for problematic inputs Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905 Reviewers: jhenderson, rupprecht, grimar Reviewed By: jhenderson, grimar Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62462 llvm-svn: 367776
* Reland "[DwarfDebug] Dump call site debug info"Djordje Todorovic2019-07-311-0/+1
| | | | | | | | | The build failure found after the rL365467 has been resolved. Differential Revision: https://reviews.llvm.org/D60716 llvm-svn: 367446
* Revert "[llvm-objdump] Add warning messages if disassembly + source for ↵Michael Pozulp2019-07-301-1/+1
| | | | | | | | | | problematic inputs" This reverts r367284 (git commit b1cbe51bdf44098c74f5c74b7bcd8c041a7c6772). My changes to LLVMSymbolizer caused a test to fail: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/29488 llvm-svn: 367286
* [llvm-objdump] Add warning messages if disassembly + source for problematic ↵Michael Pozulp2019-07-301-1/+1
| | | | | | | | | | | | | | | | | | inputs Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905 Reviewers: jhenderson, rupprecht, grimar Reviewed By: jhenderson, grimar Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62462 llvm-svn: 367284
* [DWARF][NFC] Add constants for reserved values of an initial length field.Igor Kudrin2019-07-246-10/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D65039 llvm-svn: 366887
* [DWARF] Use 32-bit format specifier for offsetJonas Devlieghere2019-07-231-7/+7
| | | | | | This should fix PR42730. llvm-svn: 366859
OpenPOWER on IntegriCloud