summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* [CodeView] Support CodeView subsections in any order.Zachary Turner2017-06-022-41/+43
| | | | | | | | | | | | | | | Previously we would expect certain subsections to appear in a certain order because some subsections would reference other subsections, but in practice we need to support arbitrary orderings since some object file and PDB file producers generate them this way. This also paves the way for supporting Yaml <-> Object File conversion of CodeView, since Object Files typically have quite a large number of subsections in their debug info. Differential Revision: https://reviews.llvm.org/D33807 llvm-svn: 304588
* [CodeView] Properly align symbol records on read/write.Zachary Turner2017-06-011-3/+3
| | | | | | | | | | | | | | | | | Object files have symbol records not aligned to any particular boundary (e.g. 1-byte aligned), while PDB files have symbol records padded to 4-byte aligned boundaries. Since they share the same reading / writing code, we have to provide an option to specify the alignment and propagate it up to the producer or consumer who knows what the alignment is supposed to be for the given container type. Added a test for this by modifying the existing PDB -> YAML -> PDB round-tripping code to round trip symbol records as well as types. Differential Revision: https://reviews.llvm.org/D33785 llvm-svn: 304484
* DbgValueHistoryCalculator: Ignore call instructions that claim to clobber SP.Adrian Prantl2017-06-012-0/+184
| | | | | | | | | | | The AArch64 backend marks calls that involve aggregate function arguments as having an implicit def of SP. We already have the same workaround in LiveDebugValues and in DbgValueHistoryCalculator for SP clobbers in register masks. This adds register defs to the list. Fixes rdar://problem/30361929 and Swift SR-3851. llvm-svn: 304471
* Mark a test as requiring a default tripleVedant Kumar2017-05-311-0/+1
| | | | | | | | | | | | | This test assumes that llc can infer a default triple. I'm not sure why exactly, but the Verify MachineInstrs bot requires tests to be explicit about this dependency. This commit follows the lead from r248452 and adds in 'REQUIRES: default_triple' to omit-empty.ll. Bot URL: http://lab.llvm.org:8080/green/job/Verify-Machineinstrs_AArch64/7500 llvm-svn: 304269
* MIR: remove explicit "noVRegs" property.Tim Northover2017-05-301-1/+0
| | | | | | | We can infer this from the incoming MIR, so there's no reason to represent it with a special flag. llvm-svn: 304246
* DebugInfo: Include .dwo file name when hashing multiple CUs in a single fileMehdi Amini2017-05-291-0/+42
| | | | | | | | | | | | | | | | | | | | | | | This is really a workaround for ThinLTO in particular - since it can import partial CUs that may end up looking very similar/the same as the same partial import in another ThinLTO compile. An alternative fix would be to change the DICompileUnit metadata to include a "primary file" or the like - and when importing for ThinLTO set the primary file to the name of the DICompileUnit that is being imported into. This involves changing the schema and would reduce the excessive uniqueness in the hash that this change creates - allowing diagnosing of more duplicate CUs than will be caught with this change. But duplicate CUs can still be caught in non-ThinLTO builds & are mostly a nuisance rather than a particularly deliberate/effective tool for finding broken code. (arguably the hash could always include the dwo file and nothing in fission would break, I think..) Reapply of r304119 after adding a triple to the test and moving it to the X86 directory. llvm-svn: 304130
* DebugInfo: Omit an empty CU when a subprogram was moved into its useMehdi Amini2017-05-291-0/+54
| | | | | | | | | | | When the only use of a CU is for a subprogram that's only emitted into the using CU (to avoid cross-CU references in DWO files), avoid creating that CU at all. Reapply of r304111 after adding a triple to the test and moving it to the X86 directory. llvm-svn: 304129
* Revert "DebugInfo: Omit an empty CU when a subprogram was moved into its use"Mehdi Amini2017-05-291-52/+0
| | | | | | | This reverts commit r304111. GreenDragon is broken. llvm-svn: 304126
* Revert "DebugInfo: Include .dwo file name when hashing multiple CUs in a ↵Mehdi Amini2017-05-292-40/+0
| | | | | | | | single file" This reverts commit r304119 and r304118. GreenDragon is broken. llvm-svn: 304125
* DebugInfo: Include .dwo file name when hashing multiple CUs in a single fileDavid Blaikie2017-05-291-0/+40
| | | | | | | | | | | | | | | | | | | | This is really a workaround for ThinLTO in particular - since it can import partial CUs that may end up looking very similar/the same as the same partial import in another ThinLTO compile. An alternative fix would be to change the DICompileUnit metadata to include a "primary file" or the like - and when importing for ThinLTO set the primary file to the name of the DICompileUnit that is being imported into. This involves changing the schema and would reduce the excessive uniqueness in the hash that this change creates - allowing diagnosing of more duplicate CUs than will be caught with this change. But duplicate CUs can still be caught in non-ThinLTO builds & are mostly a nuisance rather than a particularly deliberate/effective tool for finding broken code. (arguably the hash could always include the dwo file and nothing in fission would break, I think..) llvm-svn: 304119
* Attempt to fix buildbots...David Blaikie2017-05-291-0/+0
| | | | llvm-svn: 304118
* DebugInfo: Omit an empty CU when a subprogram was moved into its useDavid Blaikie2017-05-281-0/+52
| | | | | | | | When the only use of a CU is for a subprogram that's only emitted into the using CU (to avoid cross-CU references in DWO files), avoid creating that CU at all. llvm-svn: 304111
* DebugInfo: Add source code/build instructions for split-dwarf-dwp symbolizer ↵David Blaikie2017-05-271-0/+12
| | | | | | | | | test Addressing post-commit code review feedback from Paul Robinson on r303609. llvm-svn: 304080
* DebugInfo: Do not emit empty CUsDavid Blaikie2017-05-2611-59/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consistent with GCC and addresses a shortcoming with ThinLTO where many imported CUs may end up being empty (because the functions imported from them either ended up not being used (and were then discarded, since they're imported as available_externally) or optimized away entirely). Test cases previously testing empty CUs (either intentionally, or because they didn't need anything more complicated) had a trivial 'int' or similar basic type added to their retained types list. This is a first order approximation - a deeper implementation could do things like: 1) Be more lazy about construction of the CU - for example if two CUs containing a single identical retained type are linked together, with this change one of the two CUs will be produced but empty (since a duplicate type won't be produced). 2) Go further and invert all the CU links the same way the subprogram link is inverted - keep named CU lists of retained types, macros, etc, and have those link back to the CU. Then if they're emitted, the CU is emitted, but never otherwise - this would allow the metadata itself to be dropped earlier too, though it seems unlikely that's an important optimization as there shouldn't be many CUs relative to the number of other entities. llvm-svn: 304020
* DebugInfo: Don't include locations for debug-having code inlined into ↵David Blaikie2017-05-261-1/+8
| | | | | | | | | | | | | | | nodebug functions This produced 'strange' DWARF anyway - the CU would have no ranges (or at least not a range including the inlined code) nor any subprogram or inlined_subroutine - yet the line table would have entries for these instructions. (this actually becomes more relevant with changes coming after this, where a CU without any contents will be omitted entirely - so there would be no line table to put this on anyway) llvm-svn: 304004
* Fix test to handle running on platforms which don't enable pubnames at allDavid Blaikie2017-05-251-6/+4
| | | | | | | Check that there are no entries in the pub sections, but that they may either be not present or present-but-empty. llvm-svn: 303927
* [pdb] pad source file name buffer at the end instead of the beginningBob Haarman2017-05-253-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | Summary: DbiStreamBuilder calculated the offset of the source file names inside the file info substream as the size of the file info substream minus the size of the file names. Since the file info substream is padded to a multiple of 4 bytes, this caused the first file name to be aligned on a 4-byte boundary. By contrast, DbiModuleList would read the file names immediately after the file name offset table, without skipping to the next 4-byte boundary. This change makes it so that the file names are written to the location where DbiModuleList expects them, and puts any necessary padding for the file info substream after the file names instead of before it. Reviewers: amccarth, rnk, zturner Reviewed By: amccarth, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33475 llvm-svn: 303917
* Fix SelectionDAGBuilder::getDbgValue to not expect DW_OP_deref on FI varsAdrian Prantl2017-05-252-64/+88
| | | | | | | | | | | | This fixes an oversight in r300522, which changed alloca dbg.values to no longer emit a DW_OP_deref. The array.ll testcase was regenerated from source. Fixes PR33166: https://bugs.llvm.org/show_bug.cgi?id=33166 llvm-svn: 303897
* DebugInfo: Produce debug_{gnu_}pub{names,types} entries when explicitly ↵David Blaikie2017-05-254-4/+86
| | | | | | | | | | | | | | | | | requested, even in -gmlt or when empty Turns out gold doesn't use the DW_AT_GNU_pubnames to decide whether to parse the rest of the DIEs when building gdb-index. This causes gold to trip over LLVM's output when there are DW_FORM_ref_addr present. Gold does use the presence of a debug_gnu_pub{names,types} entry for the CU to skip parsing the debug_info portion, so make sure that's included even when empty (technically, when empty there couldn't be any ref_addr anyway - it only came up when gmlt didn't produce any (even non-empty) pubnames - but given what that reveals about gold's implementation, this seems like a good thing to do for consistency). llvm-svn: 303894
* [llvm-pdbdump] [yaml2pdb] always include object file name in module infoBob Haarman2017-05-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, the yaml2pdb subcommand of llvm-pdbdump only included object file names in module info if a module info stream was present. This change makes it so that we include the object file name even if there is no module info stream for the module. As a result, running llvm-pdbdump pdb2yaml -dbi-module-info original.pdb > original.yaml && llvm-pdbdump yaml2pdb -pdb=new.pdb original.yaml && llvm-pdbdump pdb2yaml -dbi-module-info new.pdb > new.yaml now produces identical original.yaml and new.yaml files. Reviewers: amccarth, zturner Reviewed By: zturner Subscribers: fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D33463 llvm-svn: 303891
* libDebugInfo: Support symbolizing using DWP filesDavid Blaikie2017-05-233-0/+8
| | | | llvm-svn: 303609
* Implement various flavors of type merging.Zachary Turner2017-05-229-2/+421
| | | | | | | | | | | | | | Previous algotirhm assumed that types and ids are in a single unified stream. For inputs that come from object files, this is the case. But if the input is already a PDB, or is the result of a previous merge, then the types and ids will already have been split up, in which case we need an algorithm that can accept operate on independent streams of types and ids that refer across stream boundaries to each other. Differential Revision: https://reviews.llvm.org/D33417 llvm-svn: 303577
* Don't generate line&scope debug info for meta-instructions.Adrian Prantl2017-05-221-0/+122
| | | | | | | | | | | | | | | MachineInstructions that don't generate any code (such as IMPLICIT_DEFs) should not generate any debug info either. Fixes PR33107. https://bugs.llvm.org/show_bug.cgi?id=33107 This reapplies r303566 without any modifications. The stage2 build failures persisted even after reverting this patch, and looking back through history, it looks like these tests are flaky. llvm-svn: 303575
* Revert "Don't generate line&scope debug info for meta-instructions."Adrian Prantl2017-05-221-122/+0
| | | | | | This reverts commit r303566 while investigating a stage2 buildbot failure. llvm-svn: 303570
* Don't generate line&scope debug info for meta-instructions.Adrian Prantl2017-05-221-0/+122
| | | | | | | | | | | MachineInstructions that don't generate any code (such as IMPLICIT_DEFs) should not generate any debug info either. Fixes PR33107. https://bugs.llvm.org/show_bug.cgi?id=33107 llvm-svn: 303566
* libDebugInfo/DWARF: Apply relocations for debug_addr addresses in object filesDavid Blaikie2017-05-223-0/+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-203-0/+7
| | | | llvm-svn: 303482
* Resubmit "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-191-2/+2
| | | | | | | | | | | | This was originally reverted because it was a breaking a bunch of bots and the breakage was not surfacing on Windows. After much head-scratching this was ultimately traced back to a bug in the lit test runner related to its pipe handling. Now that the bug in lit is fixed, Windows correctly reports these test failures, and as such I have finally (hopefully) fixed all of them in this patch. llvm-svn: 303446
* Revert "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-191-2/+2
| | | | | | | | | | | | | | | | | | This is a squash of ~5 reverts of, well, pretty much everything I did today. Something is seriously broken with lit on Windows right now, and as a result assertions that fire in tests are triggering failures. I've been breaking non-Windows bots all day which has seriously confused me because all my tests have been passing, and after running lit with -a to view the output even on successful runs, I find out that the tool is crashing and yet lit is still reporting it as a success! At this point I don't even know where to start, so rather than leave the tree broken for who knows how long, I will get this back to green, and then once lit is fixed on Windows, hopefully hopefully fix the remaining set of problems for real. llvm-svn: 303409
* Fix a broken test.Zachary Turner2017-05-191-2/+2
| | | | | | | | | | | | Similar to my previous fix, it turns out llvm-pdbdump has been printing an incorrect value since the beginning of time, but we didn't know it was incorrect. Specifically, we were interpreting a TypeIndex as referencing a type from the TPI stream when it actually should come from the IPI stream. So we were printing a string that looked like a valid string, but was just from the wrong place. llvm-svn: 303403
* [llvm-pdbdump] Add the ability to merge PDBs.Zachary Turner2017-05-183-0/+128
| | | | | | | | | | | | | | | Merging PDBs is a feature that will be used heavily by the linker. The functionality already exists but does not have deep test coverage because it's not easily exposed through any tools. This patch aims to address that by adding the ability to merge PDBs via llvm-pdbdump. It takes arbitrarily many PDBs and outputs a single PDB. Using this new functionality, a test is added for merging type records. Future patches will add the ability to merge symbol records, module information, etc. llvm-svn: 303389
* [llvm-pdbdump] Add the option to sort functions and data.Zachary Turner2017-05-141-2/+2
| | | | llvm-svn: 302998
* [codeview] Fix assertion failure introduced in r295354 refactoringReid Kleckner2017-05-121-0/+25
| | | | | | | | CodeViewDebug sets Asm to nullptr to disable debug info generation. You can get a .ll file like no-cus.ll from 'clang -gcodeview -g0', which happens in the ubsan test suite. llvm-svn: 302923
* DWARF: Avoid cross-CU references under FissionDavid Blaikie2017-05-121-25/+173
| | | | | | | | | | | | | | | | | | Turns out that the Fission/Split DWARF package format (DWP) is currently insufficient to handle cross-CU (ref_addr) references. So for now, duplicate any debug info needed in these situations: * inlined_subroutine's abstract_origin * inlined variable's abstract_origin * types Keep the ref_addr behavior in general, including in the split DWARF inline debug info that can be emitted into the object files for online symbolication. Keep a flag to use the old (ref_addr) behavior for testing ways of addressing this limitation in the DWP tool (& for those not using DWP packaging). llvm-svn: 302858
* [codeview] Check for a DIExpression offset for local variablesReid Kleckner2017-05-091-0/+41
| | | | | | | | Fixes inalloca parameters, which previously all pointed to the same offset. Extend the test to use llvm-readobj so that we can test the offset in a readable way. llvm-svn: 302578
* [DWARF] Fix a parsing issue with type unit headers.Wolfgang Pieb2017-05-093-0/+64
| | | | | | | | Reviewers: dblaikie Differential Revision: https://reviews.llvm.org/D32987 llvm-svn: 302574
* Re-land "Use the frame index side table for byval and inalloca arguments"Reid Kleckner2017-05-091-0/+158
| | | | | | This re-lands r302483. It was not the cause of PR32977. llvm-svn: 302544
* Re-land "Don't add DBG_VALUE instructions for static allocas in dbg.declare"Reid Kleckner2017-05-091-5/+0
| | | | | | This re-lands commit r302461. It was not the cause of PR32977. llvm-svn: 302543
* Revert "Don't add DBG_VALUE instructions for static allocas in dbg.declare"Reid Kleckner2017-05-091-0/+5
| | | | | | | | | | This reverts commit r302461. It appears to be causing failures compiling gtest with debug info on the Linux sanitizer bot. I was unable to reproduce the failure locally, however. llvm-svn: 302504
* Revert "Use the frame index side table for byval and inalloca arguments"Reid Kleckner2017-05-091-158/+0
| | | | | | This reverts r302483 and it's follow up fix. llvm-svn: 302493
* Use the frame index side table for byval and inalloca argumentsReid Kleckner2017-05-081-0/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For inalloca functions, this is a very common code pattern: %argpack = type <{ i32, i32, i32 }> define void @f(%argpack* inalloca %args) { entry: %a = getelementptr inbounds %argpack, %argpack* %args, i32 0, i32 0 %b = getelementptr inbounds %argpack, %argpack* %args, i32 0, i32 1 %c = getelementptr inbounds %argpack, %argpack* %args, i32 0, i32 2 tail call void @llvm.dbg.declare(metadata i32* %a, ... "a") tail call void @llvm.dbg.declare(metadata i32* %c, ... "b") tail call void @llvm.dbg.declare(metadata i32* %b, ... "c") Even though these GEPs can be simplified to a constant offset from EBP or RSP, we don't do that at -O0, and each GEP is computed into a register. Registers used to compute argument addresses are typically spilled and clobbered very quickly after the initial computation, so live debug variable tracking loses information very quickly if we use DBG_VALUE instructions. This change moves processing of dbg.declare between argument lowering and basic block isel, so that we can ask if an argument has a frame index or not. If the argument lives in a register as is the case for byval arguments on some targets, then we don't put it in the side table and during ISel we emit DBG_VALUE instructions. Reviewers: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32980 llvm-svn: 302483
* Don't add DBG_VALUE instructions for static allocas in dbg.declareReid Kleckner2017-05-081-5/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: An llvm.dbg.declare of a static alloca is always added to the MachineFunction dbg variable map, so these values are entirely redundant. They survive all the way through codegen to be ignored by DWARF emission. Effectively revert r113967 Two bugpoint-reduced test cases from 2012 broke as a result of this change. Despite my best efforts, I haven't been able to rewrite the test case using dbg.value. I'm not too concerned about the lost coverage because these were reduced from the test-suite, which we still run. Reviewers: aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32920 llvm-svn: 302461
* [llvm-dwarfdump] - Print an error message if section decompression failed.George Rimar2017-05-052-0/+15
| | | | | | | | | | | | | llvm-dwarfdump currently prints no message if decompression fails for some reason. I noticed that during work on one of LLD patches where LLD produced an broken output. It was a bit confusing to see no output for section dumped and no any error message at all. Patch adds error message for such cases. Differential revision: https://reviews.llvm.org/D32865 llvm-svn: 302221
* DebugInfo: elide type index entries for synthetic typesSaleem Abdulrasool2017-05-031-0/+55
| | | | | | | | | | | | | | Compiler emitted synthetic types may not have an associated DIFile (translation unit). In such a case, when generating CodeView debug type information, we would attempt to compute an absolute filepath which would result in a segfault due to a NULL DIFile*. If there is no source file associated with the type, elide the type index entry for the type and record the type information. This actually results in higher fidelity debug information than clang/C2 as of this writing. Resolves PR32668! llvm-svn: 302085
* [DWARFv5] Parse new line-table header format.Paul Robinson2017-05-023-6/+144
| | | | | | | | | | | | The directory and file tables now have form-based content descriptors. Parse these and extract the per-directory/file records based on the descriptors. For now we support only DW_FORM_string (inline) for the path names; follow-up work will add support for indirect forms (i.e., DW_FORM_strp, strx<N>, and line_strp). Differential Revision: http://reviews.llvm.org/D32713 llvm-svn: 301978
* [PDB/CodeView] Read/write codeview inlinee line information.Zachary Turner2017-05-022-4/+28
| | | | | | | | Previously we wrote line information and file checksum information, but we did not write information about inlinee lines and functions. This patch adds support for that. llvm-svn: 301936
* [CodeView] Write CodeView line information.Zachary Turner2017-05-013-2/+92
| | | | | | Differential Revision: https://reviews.llvm.org/D32716 llvm-svn: 301882
* [llvm-pdbdump] Abstract some of the YAML/Raw printing code.Zachary Turner2017-04-292-79/+87
| | | | | | | | | There is a lot of duplicate code for printing line info between YAML and the raw output printer. This introduces a base class that can be shared between the two, and makes some minor cleanups in the process. llvm-svn: 301728
* Remove line and file from DINamespace.Adrian Prantl2017-04-2817-40/+40
| | | | | | | | | | | | | | Fixes the issue highlighted in http://lists.llvm.org/pipermail/cfe-dev/2014-June/037500.html. The DW_AT_decl_file and DW_AT_decl_line attributes on namespaces can prevent LLVM from uniquing types that are in the same namespace. They also don't carry any meaningful information. rdar://problem/17484998 Differential Revision: https://reviews.llvm.org/D32648 llvm-svn: 301706
* [llvm-dwarfdump] - Change format for .gdb_index dump.George Rimar2017-04-271-2/+2
| | | | | | | | | | | | | | It is useful to output size of ranges when address ranges section of .gdb_index is dumped. It helps to compare outputs produced by different linkers, for example. In that case address ranges can look very different, when they are the same at fact. Difference comes from different low address because of different address of .text. Differential revision: https://reviews.llvm.org/D32492 llvm-svn: 301527
OpenPOWER on IntegriCloud