summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp
Commit message (Collapse)AuthorAgeFilesLines
* dwarfdump/symbolizer: Avoid loading unneeded CUs from a DWPDavid Blaikie2017-09-191-4/+4
| | | | | | | | When symbolizing large binaries, parsing every CU in a DWP file is a significant performance penalty. Instead, use the index to only load the CUs that are needed. llvm-svn: 313659
* dwarfdump: Delay parsing abbreviations until they're neededDavid Blaikie2017-09-191-4/+7
| | | | | | | | | | | This speeds up dumping specific DIEs by not parsing abbreviations for units that are not used. (this is also handy to have in eventually to speed up llvm-symbolizer for .dwp files, where parsing most of the DWP file can be avoided by using the index) llvm-svn: 313635
* [DebugInfo] - Fix for lld DWARF parsing of base address selection entries in ↵George Rimar2017-09-041-4/+5
| | | | | | | | | | | | | range lists. It solves issue of wrong section index evaluating for ranges when base address is used. Based on David Blaikie's patch D36097. Differential revision: https://reviews.llvm.org/D37214 llvm-svn: 312477
* DebugInfo: Test & handle (differently) non-zero DW_AT_ranges_baseDavid Blaikie2017-08-021-6/+7
| | | | | | | | | Followup to r309570, fixing it slightly differently (ranges_base and addr_base should never be read from a DWO file - so there shouldn't be any issue with 'overriding' the values - conditionalize the code and assert that the values aren't being overriden). llvm-svn: 309879
* [DebugInfo] Use shrink_to_fit to simplify code. NFCI.Benjamin Kramer2017-08-011-12/+2
| | | | llvm-svn: 309683
* [DebugInfo] Don't overwrite DWARFUnit fields if the CU DIE doesn't have them.Benjamin Kramer2017-07-311-2/+6
| | | | | | | | | | DIEs are lazily deserialized so it's possible that the DWO CU is created before the DIE is parsed. DWO shares .debug_addr and .debug_ranges with the object file so overwriting the offset with 0 will make the CU unusable. No test case because I couldn't get clang to emit a non-zero range base. llvm-svn: 309570
* Use delegation instead of inheritance.Rafael Espindola2017-07-191-11/+19
| | | | | | | | | | This changes DwarfContext to delegate to DwarfObject instead of having pure virtual methods. With this DwarfContextInMemory is replaced with an implementation of DwarfObject that is local to a .cpp file. llvm-svn: 308543
* [DWARF] NFC: DWARFDataExtractor combines relocs with DataExtractor.Paul Robinson2017-06-291-18/+14
| | | | | | | | | | | Requires callers to directly associate relocations with a DataExtractor used to read data from a DWARF section, which helps a callee not make assumptions about which section it is reading. This is the next step in reducing DWARFFormValue's dependence on DWARFUnit. Differential Revision: https://reviews.llvm.org/D34704 llvm-svn: 306699
* [DWARF] NFC: Make string-offset handling more like address-table handling; Paul Robinson2017-06-271-11/+3
| | | | | | do the indirection and relocation all in the same method. llvm-svn: 306418
* [DWARF] NFC: Collect info used by DWARFFormValue into a helper.Paul Robinson2017-06-261-14/+18
| | | | | | | | | | | Some forms have sizes that depend on the DWARF version, DWARF format (32/64-bit), or the size of an address. Collect these into a struct to simplify passing them around. Require callers to provide one when they query a form's size. Differential Revision: http://reviews.llvm.org/D34570 llvm-svn: 306315
* [DebugInfo] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-06-231-6/+4
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 306169
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [DWARF] Adding support for the DWARF v5 string offsets table ↵Wolfgang Pieb2017-06-061-19/+37
| | | | | | | | | | (consumer/reader part only). Reviewers: dblaikie, aprantl Differential Revision: https://reviews.llvm.org/D32779 llvm-svn: 304759
* libDebugInfo: Support symbolizing using DWP filesDavid Blaikie2017-05-231-6/+3
| | | | llvm-svn: 303609
* FIX: Remove debugging assert left in previous commitDavid Blaikie2017-05-231-1/+0
| | | | | | Sorry for the bot noise. llvm-svn: 303592
* libDebugInfo: Avoid independently parsing the same .dwo file for two ↵David Blaikie2017-05-231-27/+16
| | | | | | | | | separate CUs residing there NFC, just an optimization. Will be building on this for DWP support shortly. llvm-svn: 303591
* libDebugInfo/DWARF: Apply relocations for debug_addr addresses in object filesDavid Blaikie2017-05-221-7/+7
| | | | | | | | | | | llvm-symbolizer would fail to symbolize addresses in unlinked object files when handling .dwo file data because the addresses would not be relocated in the same way as the ranges in the skeleton CU in the object file. Fix that so object files can be symbolized the same as executables. llvm-svn: 303532
* llvm-symbolizer: Support multiple CUs in a single DWO fileDavid Blaikie2017-05-201-6/+11
| | | | llvm-svn: 303482
* [DWARF] - Use DWARFAddressRange struct instead of uint64_t pair for ↵George Rimar2017-05-161-8/+8
| | | | | | | | | | | DWARFAddressRangesVector. Recommit of r303159 "[DWARF] - Use DWARFAddressRange struct instead of uint64_t pair for DWARFAddressRangesVector" All places were shitched to use DWARFAddressRange now. Suggested during review of D33184. llvm-svn: 303163
* [DWARF] - Take relocations in account when extracting ranges from .debug_rangesGeorge Rimar2017-04-241-7/+9
| | | | | | | | | | | | | | | I found this when investigated "Bug 32319 - .gdb_index is broken/incomplete" for LLD. When we have object file with .debug_ranges section it may be filled with zeroes. Relocations are exist in file to relocate this zeroes into real values later, but until that a pair of zeroes is treated as terminator. And DWARF parser thinks there is no ranges at all when I am trying to collect address ranges for building .gdb_index. Solution implemented in this patch is to take relocations in account when parsing ranges. Differential revision: https://reviews.llvm.org/D32228 llvm-svn: 301170
* Code style change as suggested in https://reviews.llvm.org/D32177 (NFC)Dehao Chen2017-04-191-16/+11
| | | | llvm-svn: 300753
* Using address range map to speedup finding inline stack for address.Dehao Chen2017-04-191-17/+48
| | | | | | | | | | | | | | | | | | | | Summary: In the current implementation, to find inline stack for an address incurs expensive linear search in 2 places: * linear search for the top-level DIE * recursive linear traverse the DIE tree to find the path to the leaf DIE In this patch, a map is built from address to its corresponding leaf DIE. The inline stack is built by traversing from the leaf DIE up to the root DIE. This speeds up batch symbolization by ~10X without noticible memory overhead. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32177 llvm-svn: 300742
* Revert r300697 which causes buildbot failure.Dehao Chen2017-04-191-47/+17
| | | | llvm-svn: 300708
* Using address range map to speedup finding inline stack for address.Dehao Chen2017-04-191-17/+47
| | | | | | | | | | | | | | | | | | | | Summary: In the current implementation, to find inline stack for an address incurs expensive linear search in 2 places: * linear search for the top-level DIE * recursive linear traverse the DIE tree to find the path to the leaf DIE In this patch, a map is built from address to its corresponding leaf DIE. The inline stack is built by traversing from the leaf DIE up to the root DIE. This speeds up batch symbolization by ~10X without noticible memory overhead. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32177 llvm-svn: 300697
* [DebugInfo] Fix some Include What You Use warnings; other minor fixes (NFC).Eugene Zelenko2017-03-011-12/+12
| | | | llvm-svn: 296559
* [DWARFv5] Emit new unit header format.Paul Robinson2017-02-281-2/+9
| | | | | | | | | Requesting DWARF v5 will now get you the new compile-unit and type-unit headers. llvm-dwarfdump will also recognize them. Differential Revision: http://reviews.llvm.org/D30206 llvm-svn: 296514
* Add a variant of DWARFDie::find() and DWARFDie::findRecursively() that takes ↵Greg Clayton2017-01-131-3/+1
| | | | | | | | | | a llvm::ArrayRef<dwarf::Attribute>. This allows us efficiently look for more than one attribute, something that is quite common in DWARF consumption. Differential Revision: https://reviews.llvm.org/D28704 llvm-svn: 291967
* Cleanup how DWARFDie attributes are accessed and decoded.Greg Clayton2017-01-131-17/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removed all DWARFDie::getAttributeValueAs*() calls. Renamed: Optional<DWARFFormValue> DWARFDie::getAttributeValue(dwarf::Attribute); To: Optional<DWARFFormValue> DWARFDie::find(dwarf::Attribute); Added: Optional<DWARFFormValue> DWARFDie::findRecursively(dwarf::Attribute); All decoding of Optional<DWARFFormValue> values are now done using the dwarf::to*() functions from DWARFFormValue.h: Old code: auto DeclLine = DWARFDie.getAttributeValueAsSignedConstant(DW_AT_decl_line).getValueOr(0); New code: auto DeclLine = toUnsigned(DWARFDie.find(DW_AT_decl_line), 0); This composition helps us since we can now easily do: auto DeclLine = toUnsigned(DWARFDie.findRecursively(DW_AT_decl_line), 0); This allows us to easily find attribute values in the current DIE only (the first new code above) or in any DW_AT_abstract_origin or DW_AT_specification Dies using the line above. Note that the code line length is shorter and more concise. Differential Revision: https://reviews.llvm.org/D28581 llvm-svn: 291959
* Remove all variants of DWARFDie::getAttributeValueAs...() that had ↵Greg Clayton2017-01-111-4/+6
| | | | | | | | | | parameters that specified default values. Now we only support returning Optional<> values and have changed all clients over to use Optional::getValueOr(). Differential Revision: https://reviews.llvm.org/D28569 llvm-svn: 291686
* Add the ability for DWARFDie objects to get the parent DWARFDie.Greg Clayton2016-12-211-31/+40
| | | | | | | | | | | | In order for the llvm DWARF parser to be used in LLDB we will need to be able to get the parent of a DIE. This patch adds that functionality by changing the DWARFDebugInfoEntry class to store a depth field instead of a sibling index. Using a depth field allows us to easily calculate the sibling and the parent without increasing the size of DWARFDebugInfoEntry. I tested llvm-dsymutil on a debug version of clang where this fully parses DWARF in over 1200 .o files to verify there was no serious regression in performance. Added a full suite of unit tests to test this functionality. Differential Revision: https://reviews.llvm.org/D27995 llvm-svn: 290274
* Revert "dwarfdump: Support/process relocations on a CU's abbrev_off"David Blaikie2016-12-161-3/+0
| | | | | | | | | Reverting because this breaks lld's gdb_index support - it's probably double counting the abbrev relocation offset. This reverts commit r289954. llvm-svn: 289961
* dwarfdump: Support/process relocations on a CU's abbrev_offDavid Blaikie2016-12-161-0/+3
| | | | | | | | | | Input can be produced by ld -r, for example (a normal LLVM workflow never hits this - LLVM only ever produces a single abbrev table in an object (shared by multiple CUs), so the reloc's always 0, and when it's linked together the relocation's resolved so it doesn't need to be handled) llvm-svn: 289954
* Add the ability to get attribute values as Optional<T>Greg Clayton2016-12-141-9/+9
| | | | | | | | | | | | | | | | | | | | | | When getting attributes it is sometimes nicer to use Optional<T> some of the time instead of magic values. I tried to cut over to only using the Optional values but it made many of the call sites very messy, so it makes sense the leave in the calls that can return a default value. Otherwise code that looks like this: uint64_t CallColumn = Die.getAttributeValueAsAddress(DW_AT_call_line, 0); Has to be turned into: uint64_t CallColumn = 0; if (auto CallColumnValue = Die.getAttributeValueAsAddress(DW_AT_call_line)) CallColumn = *CallColumnValue; The first snippet of code looks much better. But in cases where you want an offset that may or may not be there, the following code looks better: if (auto StmtOffset = Die.getAttributeValueAsSectionOffset(DW_AT_stmt_list)) { // Use StmtOffset } Differential Revision: https://reviews.llvm.org/D27772 llvm-svn: 289731
* Make a DWARFDIE class that can help avoid using the wrong DWARFUnit when ↵Greg Clayton2016-12-131-48/+42
| | | | | | | | | | | | extracting attributes Many places pass around a DWARFDebugInfoEntryMinimal and a DWARFUnit. It is easy to get things wrong by using the wrong DWARFUnit with a DWARFDebugInfoEntryMinimal. This patch creates a DWARFDie class that contains the DWARFUnit and DWARFDebugInfoEntryMinimal objects so that they can't get out of sync. All attribute extraction has been moved out of DWARFDebugInfoEntryMinimal and into DWARFDie. DWARFDebugInfoEntryMinimal was also renamed to DWARFDebugInfoEntry. DWARFDie objects are temporary objects that are used by clients and contain 2 pointers that you always need to have anyway. Keeping them grouped will avoid errors and simplify many of the attribute extracting APIs by not having to pass in a DWARFUnit. Differential Revision: https://reviews.llvm.org/D27634 llvm-svn: 289565
* [DebugInfo] Fix some Clang-tidy modernize-use-default and Include What You ↵Eugene Zelenko2016-11-231-10/+21
| | | | | | | | Use warnings; other minor fixes (NFC). Per Zachary Turner and Mehdi Amini suggestion to make only post-commit reviews. llvm-svn: 287838
* Improve DWARF parsing speed by improving DWARFAbbreviationDeclarationGreg Clayton2016-11-151-1/+2
| | | | | | | | | | | | | | | | | | | | This patch gets a DWARF parsing speed improvement by having DWARFAbbreviationDeclaration instances know if they have a fixed byte size. If an abbreviation has a fixed byte size that can be calculated given a DWARFUnit, then parsing a DIE becomes two steps: parse ULEB128 abbrev code, and then add constant size to the offset. This patch also adds a fixed byte size to each DWARFAbbreviationDeclaration::AttributeSpec so that attributes can quickly skip their values if needed without the need to lookup the fixed for size. Notable improvements: - DWARFAbbreviationDeclaration::findAttributeIndex() now returns an Optional<uint32_t> instead of a uint32_t and we no longer have to look for the magic -1U return value - Optional<uint32_t> DWARFAbbreviationDeclaration::findAttributeIndex(dwarf::Attribute attr) const; - DWARFAbbreviationDeclaration now has a getAttributeValue() function that extracts an attribute value given a DIE offset that takes advantage of the DWARFAbbreviationDeclaration::AttributeSpec::ByteSize - bool DWARFAbbreviationDeclaration::getAttributeValue(const uint32_t DIEOffset, const dwarf::Attribute Attr, const DWARFUnit &U, DWARFFormValue &FormValue) const; - A DWARFAbbreviationDeclaration instance can return a fixed byte size for itself so DWARF parsing is faster: - Optional<size_t> DWARFAbbreviationDeclaration::getFixedAttributesByteSize(const DWARFUnit &U) const; - Any functions that used to take a "const DWARFUnit *U" that would crash if U was NULL now take a "const DWARFUnit &U" and are only called with a valid DWARFUnit Differential Revision: https://reviews.llvm.org/D26567 llvm-svn: 286924
* Import/update constants from the DWARF 5 public review draft document.Adrian Prantl2016-10-281-1/+1
| | | | | | https://reviews.llvm.org/D26051 llvm-svn: 285421
* llvm-symbolizer: Avoid infinite recursion walking dwos where the dwo ↵David Blaikie2016-04-221-5/+8
| | | | | | | | | | | contains a dwo_name attribute The dwo_name was added to dwo files to improve diagnostics in dwp, but it confuses tools that attempt to load any dwo named by a dwo_name, even ones inside dwos. Avoid this by keeping track of whether a unit is already a dwo unit, and if so, not loading further dwos. llvm-svn: 267241
* llvm-symbolizer: prefer .dwo contents over fission-gmlt-like-data when .dwo ↵David Blaikie2016-04-221-12/+7
| | | | | | | | | | | | | | | | | | | | | file is present Rather than relying on the gmlt-like data emitted into the .o/executable which only contains the simple name of any inlined functions, use the .dwo file if present. Test symbolication with/without a .dwo, and the old test that was testing behavior when no gmlt-like data was present. (I haven't included a test of non-gmlt-like data + no .dwo (that would be akin to symbolication with no debug info) but we could add one for completeness) The test was simplified a bit to be a little clearer (unoptimized, force inline, using a function call as the inlined entity) and regenerated with ToT clang. For the no-gmlt-like-data case, I modified Clang back to its old behavior temporarily & the .dwo file is identical so it is shared between the two executables. llvm-svn: 267227
* Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby2016-04-061-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to produce a real error message Produce the first specific error message for a malformed Mach-O file describing the problem instead of the generic message for object_error::parse_failed of "Invalid data was encountered while parsing the file”.  Many more good error messages will follow after this first one. This is built on Lang Hames’ great work of adding the ’Error' class for structured error handling and threading Error through MachOObjectFile construction. And making createMachOObjectFile return Expected<...> . So to to get the error to the llvm-obdump tool, I changed the stack of these methods to also return Expected<...> : object::ObjectFile::createObjectFile() object::SymbolicFile::createSymbolicFile() object::createBinary() Then finally in ParseInputMachO() in MachODump.cpp the error can be reported and the specific error message can be printed in llvm-objdump and can be seen in the existing test case for the existing malformed binary but with the updated error message. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now use of errorToErrorCode() and errorOrToExpected() are used where the callers are yet to be converted. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values. So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(ObjOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 265606
* Fix null dereference committed in r253277David Blaikie2015-11-171-2/+3
| | | | llvm-svn: 253393
* dwarfdump: support indexed string dumping in dwp based on the STR_OFFSETS ↵David Blaikie2015-11-171-1/+5
| | | | | | component of the index llvm-svn: 253392
* dwarfdump: Reference the appropriate line table segment when dumping dwp filesDavid Blaikie2015-11-171-5/+6
| | | | | | Also improves .dwo type unit dumping which didn't handle this either. llvm-svn: 253377
* dwarfdump: Use the index to find the right abbrev offset in DWP filesDavid Blaikie2015-11-171-4/+26
| | | | llvm-svn: 253277
* Refactor: Simplify boolean conditional return statements in ↵Benjamin Kramer2015-05-251-4/+1
| | | | | | | | | | | llvm/lib/DebugInfo/DWARF Use clang-tidy to simplify boolean conditional return statements. Patch by Richard Thomson <legalize@xmission.com>! Differential Revision: http://reviews.llvm.org/D9972 llvm-svn: 238132
* [DWARF parser] Make DWARF parser more robust against missing compile/type units.Alexey Samsonov2015-05-191-2/+5
| | | | | | | | | | | | | | | | | | DWARF standard claims that each compilation/type unit header in .debug_info/.debug_types section must be followed by corresponding compile/type unit DIE, possibly with its children. Two situations are possible: * compile/type unit DIE is missing because DWARF producer failed to emit it. * DWARF parser failed to parse unit DIE correctly, for instance if it contains some unsupported attributes (see r237721, for instance). In either of these cases, the library, and the tools that use it (llvm-dwarfdump, llvm-symbolizer) should not crash. Insert appropriate checks to protect against this. llvm-svn: 237733
* Move DIContext.h to common DebugInfo location.Zachary Turner2015-04-231-1/+1
| | | | | | | | | | This will enable us to create a PDBContext so as to expose some amount of debug info functionality through a common interace. Differential Revision: http://reviews.llvm.org/D9205 Reviewed by: Alexey Samsonov llvm-svn: 235612
* Move DebugInfo to DebugInfo/DWARF.Zachary Turner2015-01-301-0/+377
In preparation for adding PDB support to LLVM, this moves the DWARF parsing code to its own subdirectory under DebugInfo, and renames LLVMDebugInfo to LLVMDebugInfoDWARF. This is purely a mechanical / build system change. Differential Revision: http://reviews.llvm.org/D7269 Reviewed by: Eric Christopher llvm-svn: 227586
OpenPOWER on IntegriCloud