summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* AMDGPU: Fix assert in schedulerKonstantin Zhuravlyov2017-04-271-0/+95
| | | | | | | | Assert is triggered if DBG_VALUE is first instruction in BB Differential Revision: https://reviews.llvm.org/D32572 llvm-svn: 301511
* Revert r301487: Replace HashString algorithm with xxHash64Rui Ueyama2017-04-263-19/+16
| | | | | | This reverts commit r301487 to make buildbots green. llvm-svn: 301491
* Add support for DW_TAG_thrown_type.Adrian Prantl2017-04-261-0/+38
| | | | | | | | | | | | | | | | | | | | For Swift we would like to be able to encode the error types that a function may throw, so the debugger can display them alongside the function's return value when finish-ing a function. DWARF defines DW_TAG_thrown_type (intended to be used for C++ throw() declarations) that is a perfect fit for this purpose. This patch wires up support for DW_TAG_thrown_type in LLVM by adding a list of thrown types to DISubprogram. To offset the cost of the extra pointer, there is a follow-up patch that turns DISubprogram into a variable-length node. rdar://problem/29481673 Differential Revision: https://reviews.llvm.org/D32559 llvm-svn: 301489
* Replace HashString algorithm with xxHash64Rui Ueyama2017-04-263-16/+19
| | | | | | | | | | | | The previous algorithm processed one character at a time, which is very painful on a modern CPU. Replace it with xxHash64, which both already exists in the codebase and is fairly fast. Patch from Scott Smith! Differential Revision: https://reviews.llvm.org/D32509 llvm-svn: 301487
* [llvm-pdbdump] Dump File / Line Info to YAML.Zachary Turner2017-04-251-0/+59
| | | | | | | | | We were already parsing and dumping this to the human readable format, but not to the YAML format. This does so, in preparation for reading it in and reconstructing the line information from YAML. llvm-svn: 301357
* Fix an assertion when skipping stack values in DWARF2 mode.Adrian Prantl2017-04-251-0/+96
| | | | | | | | The fix consists of resetting LocationKind when addMachineRegExpression fails. rdar://problem/31803010 llvm-svn: 301351
* Print complete DIExpressions in the assembler output DEBUG_VALUE comments.Adrian Prantl2017-04-256-19/+19
| | | | | | The previous code was complex, incorrect, and couldn't print everything. llvm-svn: 301333
* Add a testcase for DIExpression(DW_OP_stack_value)Adrian Prantl2017-04-241-0/+123
| | | | | | | | and relax the assertion that prohibited its emission. This fixes the assertion failure uncovered by r301093. llvm-svn: 301209
* [DWARF] Move test to x86 directoryRenato Golin2017-04-241-0/+0
| | | | llvm-svn: 301176
* [DWARF] - Take relocations in account when extracting ranges from .debug_rangesGeorge Rimar2017-04-241-0/+70
| | | | | | | | | | | | | | | 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
* Fix test to handle .rel and .rela sections (& to actually specify the target ↵David Blaikie2017-04-221-4/+4
| | | | | | architecture as X86) llvm-svn: 301073
* Avoid using relocations for ref_addr in .dwo filesDavid Blaikie2017-04-221-0/+46
| | | | | | | | | | In dwo files the fixed offset can be used - if the dwos are linked into a dwp, the dwo consumer must use the dwp tables to find out where the original range of the debug_info was and resolve the "section relative" value relative to that original range - effectively avoiding/reimplementing the relocation handling. llvm-svn: 301072
* Move Split DWARF handling to an MC option/command line argument rather than ↵David Blaikie2017-04-2115-17/+17
| | | | | | | | | | | | | | | | | | | using metadata Since Split DWARF needs to name the actual .dwo file that is generated, it can't be known at the time the llvm::Module is produced as it may be merged with other Modules before the object is generated and that object may be generated with any name. By passing the Split DWARF file name when LLVM is producing object code the .dwo file name in the object file can match correctly. The support for Split DWARF for implicit modules remains the same - using metadata to store the dwo name and dwo id so that potentially multiple skeleton CUs referring to different dwo files can be generated from one llvm::Module. llvm-svn: 301062
* Don't emit locations that need a DW_OP_stack_value in DWARF 2 & 3.Adrian Prantl2017-04-201-0/+9
| | | | | | https://bugs.llvm.org/show_bug.cgi?id=32382 llvm-svn: 300883
* [DWARF] Versioning for DWARF constants; verify FORMsPaul Robinson2017-04-202-162/+0
| | | | | | | | | | | | | Associate the version-when-defined with definitions of standard DWARF constants. Identify the "vendor" for DWARF extensions. Use this information to verify FORMs in .debug_abbrev are defined as of the DWARF version specified in the associated unit. Removed two tests that had specified DWARF v1 (which essentially does not exist). Differential Revision: http://reviews.llvm.org/D30785 llvm-svn: 300875
* Fix bug that caused DwarfExpression to drop DW_OP_deref from FI locationsAdrian Prantl2017-04-191-0/+35
| | | | | | | | | | | - introduced in r300522 and found via the Swift LLDB testsuite. The fix is to set the location kind to memory whenever an FrameIndex location is emitted. rdar://problem/31707602 llvm-svn: 300793
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-188-24/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* AMDGPU: Test handling of R_AMDGPU_ABS64 in RelocVisitorKonstantin Zhuravlyov2017-04-171-0/+72
| | | | llvm-svn: 300472
* AMDGPU: Set CodePointerSize to 8 for amdgcnKonstantin Zhuravlyov2017-04-172-2/+75
| | | | llvm-svn: 300470
* [llvm-pdbdump] More advanced class definition dumping.Zachary Turner2017-04-122-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
* [PDB] Emit index/offset pairs for TPI and IPI streamsReid Kleckner2017-04-111-0/+74
| | | | | | | | | | | | | | | | | | | Summary: This lets PDB readers lookup type record data by type index in O(log n) time. It also enables makes `cvdump -t` work on PDBs produced by LLD. cvdump will not dump a PDB that doesn't have an index-to-offset table. The table is sorted by type index, and has an entry every 8KB. Looking up a type record by index is a binary search of this table, followed by a scan of at most 8KB. Reviewers: ruiu, zturner, inglorion Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31636 llvm-svn: 299958
* [StripDeadDebug/DIFinder] Track inlined SPsKeno Fischer2017-04-111-0/+31
| | | | | | | | | | | | | | | | | | | | Summary: In rL299692 I improved strip-dead-debug-info's ability to drop CUs that are not referenced from the current module. However, in doing so I neglected to realize that some SPs could be referenced entirely from inlined functions. It appears I was not the only one to make this mistake, because DebugInfoFinder, doesn't find those SPs either. Fix this in DebugInfoFinder and then use that to make sure not to drop those CUs in strip-dead-debug-info. Reviewers: aprantl Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31904 llvm-svn: 299936
* [llvm-pdbdump] Display padding bytes on record layoutZachary Turner2017-04-101-22/+24
| | | | | | | | | | | | | | | When dumping classes, show where padding occurs, and at the end of the class print statistics about how many bytes total of padding exist in a class. Since PDB doesn't specifically contain information about padding, we have to mimic this by sort of reversing a small portion of the record layout algorithm (e.g. looking at offsets and sizes and trying to determine whether something is part of the same field or a new field). Differential Revision: https://reviews.llvm.org/D31800 llvm-svn: 299869
* Improves pretty printing of variable types in llvm-pdbdumpAdrian McCarthy2017-04-104-9/+28
| | | | | | | | | | | | | | | | | * Adds support for pointers to arrays, which was missing * Adds some tests * Improves consistency of const and volatile qualifiers * Eliminates non-composable special case code for arrays and function by using a more general recursive approach * Has a hack for getting the calling convention into the right spot for pointer-to-functions Given the rapid changes happenning in llvm-pdbdump, this may be difficult to merge. Differential Revision: https://reviews.llvm.org/D31832 llvm-svn: 299848
* Allow specification of what kinds of class members to dump.Zachary Turner2017-04-061-1/+0
| | | | | | | | | | | | | | Previously when dumping class definitions, there were only two modes - on or off. But it's useful to sometimes get a little more fine-grained. For example, you might only want to see the record layout (for example to look for extraneous padding). This patch adds a third mode, layout mode, which does exactly that. Only this-relative data members are displayed in this mode. Differential Revision: https://reviews.llvm.org/D31794 llvm-svn: 299733
* Improve DebugInfo/strip-loop-metadata.ll testAdam Nemet2017-03-311-1/+10
| | | | | | | This wasn't covering for the case where you have multiple latches and hence the use of the same loop-id which needs to be mapped to the same loop-id. llvm-svn: 299237
* If the DIUnit has flags passed on it then have DW_AT_producer be a ↵Eric Christopher2017-03-291-0/+44
| | | | | | | | | | combination of DICompileUnit::Producer and Flags. The darwin behavior is unchanged and will continue to use DW_AT_APPLE_flags. Patch by Zhizhou Yang llvm-svn: 299038
* Re-land: "Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]"Adrian McCarthy2017-03-291-0/+11
| | | | | | | | | | | | | | This should work on all platforms now that r299006 has landed. Tested locally on Windows and Linux. This moves exe symbol-specific method implementations out of NativeRawSymbol into a concrete subclass. Also adds implementations for hasCTypes and hasPrivateSymbols and a simple test to ensure the native reader can access the summary information for the executable from the PDB. Original Differential Revision: https://reviews.llvm.org/D31059 llvm-svn: 299019
* [codeview] Don't assert when the user violates the ODRReid Kleckner2017-03-241-0/+100
| | | | | | | | | | If we have an array of a user-defined aggregates for which there was an ODR violation, then the array size will not necessarily match the number of elements times the size of the element. Fixes PR32383 llvm-svn: 298750
* Make testcase less nonsensical while still exercising the same code paths.Adrian Prantl2017-03-241-20/+24
| | | | llvm-svn: 298726
* Fix a bug when emitting debug info for partially constant global variables.Adrian Prantl2017-03-231-1/+1
| | | | | | | While fixing a malformed testcase, I discovered that the code exercised by it was wrong, too. llvm-svn: 298664
* [PDB] Use two DBs when dumping the IPI streamReid Kleckner2017-03-231-29/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When dumping these records from an object file section, we should use only one type database. However, when dumping from a PDB, we should use two: one for the type stream and one for the IPI stream. Certain type records that normally live in the .debug$T object file section get moved over to the IPI stream of the PDB file and they get new indices. So far, I've noticed that the MSVC linker always moves these records into IPI: - LF_FUNC_ID - LF_MFUNC_ID - LF_STRING_ID - LF_SUBSTR_LIST - LF_BUILDINFO - LF_UDT_MOD_SRC_LINE These records have index fields that can point into TPI or IPI. In particular, LF_SUBSTR_LIST and LF_BUILDINFO point to LF_STRING_ID records to describe compilation command lines. I've modified the dumper to have an optional pointer to the item DB, and to do type name lookup of these fields in that DB. See printItemIndex. The result is that our pdbdump-headers.test is more faithful to the PDB contents and the output is less confusing. Reviewers: ruiu Subscribers: amccarth, zturner, llvm-commits Differential Revision: https://reviews.llvm.org/D31309 llvm-svn: 298649
* Somehow this still breaks because of ANSI color codes in test output on Linux.Adrian McCarthy2017-03-231-11/+0
| | | | | | | | | | Reverting until I can figure out the root cause. Revert "Re-land: Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]" This reverts commit f461a70cc376f0f91c8b4917be79479cc86330a5. llvm-svn: 298626
* Fix build break after r298623Adrian McCarthy2017-03-231-1/+1
| | | | | | | Use the -color-output option explicitly to eliminate the ANSI color codes in pdb-native-summary.test. (The default should have done this.) llvm-svn: 298625
* Re-land: Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]Adrian McCarthy2017-03-231-0/+11
| | | | | | | | | | | | | | The new test should pass on all platforms now that llvm-pdbdump has the `-color-output` option. This moves exe symbol-specific method implementations out of NativeRawSymbol into a concrete subclass. Also adds implementations for hasCTypes and hasPrivateSymbols and a simple test to ensure the native reader can access the summary information for the executable from the PDB. Original Differential Revision: https://reviews.llvm.org/D31059 llvm-svn: 298623
* Fix testcase on windows.Adrian Prantl2017-03-221-1/+1
| | | | llvm-svn: 298521
* Fix PR32298 by adding an early exit to getFrameIndexExprs().Adrian Prantl2017-03-221-0/+40
| | | | | | | | Also add an assertion for the case that there are multiple FI expressions with a DW_OP_LLVM_fragment; which should violate internal constraints in DbgVariable. llvm-svn: 298518
* [codeview] Use separate records for LF_SUBSTR_LIST and LF_ARGLISTReid Kleckner2017-03-221-3/+3
| | | | | | | They are structurally the same, but now we need to distinguish them because one record lives in the IPI stream and the other lives in TPI. llvm-svn: 298474
* Don't compose DWARF expressions with multiple subregisters.Adrian Prantl2017-03-221-0/+122
| | | | | | | | | If a register location can only be described by a complex expression (i.e., multiple subregisters) it doesn't safely compose with another complex expression. For example, it is not possible to apply a DW_OP_deref operation to multiple DW_OP_pieces. llvm-svn: 298472
* Revert 298388 and 298389 because they broke some AMDGPU tests.Adrian Prantl2017-03-211-122/+0
| | | | llvm-svn: 298401
* Don't compose DWARF expressions with multiple subregisters.Adrian Prantl2017-03-211-0/+122
| | | | | | | | | If a register location can only be described by a complex expression (i.e., multiple subregisters) it doesn't safely compose with another complex expression. For example, it is not possible to apply a DW_OP_deref operation to multiple DW_OP_pieces. llvm-svn: 298389
* Enable stripping of multiple DILocation on !llvm.loop metadataTeresa Johnson2017-03-191-0/+44
| | | | | | | | | | | | | | | | | Summary: I found that stripDebugInfo was still leaving significant amounts of debug info due to !llvm.loop that contained DILocation after stripping. The support for stripping debug info on !llvm.loop added in r293377 only removes a single DILocation. Enhance that to remove all DILocation from !llvm.loop. Reviewers: hfinkel, aprantl, dsanders Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31117 llvm-svn: 298213
* Revert "Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]"Zachary Turner2017-03-171-11/+0
| | | | | | | For some reason this is causing ANSI color codes to be printed even when run through FileCheck. llvm-svn: 298026
* [pdb] Fix an uninitialized read, and add a test for it.Zachary Turner2017-03-172-0/+29
| | | | | | | | | | | | | | | | | | | This was originally reported in pr32249, uncovered by PTVS-Studio. There was no code coverage for this path because it was difficult to construct odd-case PDB files that were not generated by cl. Now that we can write construct minimal PDB files from YAML, it's easy to construct fragments that generate whatever we want. In this patch I add a test that creates 2 type records. One with a unique name, and one without. I verify that we can go from PDB to Yaml with no errors. In a future patch I'd like to add something like llvm-pdbdump raw -lookup-type that will just dump one record and nothing else, which should make it a bit cleaner to find this kind of thing. llvm-svn: 298017
* Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]Adrian McCarthy2017-03-161-0/+11
| | | | | | | | | | | This moves exe symbol-specific method implementations out of NativeRawSymbol into a concrete subclass. Also adds implementations for hasCTypes and hasPrivateSymbols and a simple test to ensure the native reader can access the summary information for the executable from the PDB. Differential Revision: https://reviews.llvm.org/D31059 llvm-svn: 298005
* [PDB] Add support for parsing Flags from PDB Stream.Zachary Turner2017-03-163-0/+5
| | | | | | | | | | | | | | | | | | | This was discovered when running `llvm-pdbdump diff` against two files, the second of which was generated by running the first one through pdb2yaml and then yaml2pdb. The second one was missing some bytes from the PDB Stream, and tracking this down showed that at the end of the PDB Stream were some additional bytes that we were ignoring. Looking back to the reference code, these seem to specify some additional flags that indicate whether the PDB supports various optional features. This patch adds support for reading, writing, and round-tripping these flags through YAML and the raw dumper, and updates the tests accordingly. llvm-svn: 297984
* PR32288: More efficient encoding for DWARF expr subregister access.Adrian Prantl2017-03-169-23/+20
| | | | | | | | | | | | | | | | | | | | | | | Citing http://bugs.llvm.org/show_bug.cgi?id=32288 The DWARF generated by LLVM includes this location: 0x55 0x93 0x04 DW_OP_reg5 DW_OP_piece(4) When GCC's DWARF is simply 0x55 (DW_OP_reg5) without the DW_OP_piece. I believe it's reasonable to assume the DWARF consumer knows which part of a register logically holds the value (low bytes, high bytes, how many bytes, etc) for a primitive value like an integer. This patch gets rid of the redundant DW_OP_piece when a subregister is at offset 0. It also adds previously missing subregister masking when a subregister is followed by another operation. (This reapplies r297960 with two additional testcase updates). rdar://problem/31069390 https://reviews.llvm.org/D31010 llvm-svn: 297965
* Revert "PR32288: More efficient encoding for DWARF expr subregister access."Adrian Prantl2017-03-169-20/+23
| | | | | | This reverts commit 2bf453116889a576956892ea9683db4fcd96e30e while investigating buildbot breakage. llvm-svn: 297962
* PR32288: More efficient encoding for DWARF expr subregister access.Adrian Prantl2017-03-169-23/+20
| | | | | | | | | | | | | | | | | | | | | Citing http://bugs.llvm.org/show_bug.cgi?id=32288 The DWARF generated by LLVM includes this location: 0x55 0x93 0x04 DW_OP_reg5 DW_OP_piece(4) When GCC's DWARF is simply 0x55 (DW_OP_reg5) without the DW_OP_piece. I believe it's reasonable to assume the DWARF consumer knows which part of a register logically holds the value (low bytes, high bytes, how many bytes, etc) for a primitive value like an integer. This patch gets rid of the redundant DW_OP_piece when a subregister is at offset 0. It also adds previously missing subregister masking when a subregister is followed by another operation. rdar://problem/31069390 https://reviews.llvm.org/D31010 llvm-svn: 297960
* [pdb] Write the module info and symbol record streams.Zachary Turner2017-03-153-4/+22
| | | | | | | | | | | Previously we did not have support for writing detailed module information for each module, as well as the symbol records. This patch adds support for this, and in doing so enables the ability to construct minimal PDBs from just a few lines of YAML. A test is added to illustrate this functionality. llvm-svn: 297900
OpenPOWER on IntegriCloud