summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[DebugInfo] Make describeLoadedValue() reg aware"David Stenberg2019-12-094-535/+3
| | | | | This reverts commit 3cd93a4efcdeabeb20cb7bec9fbddcb540d337a1. I'll recommit with a well-formatted arcanist commit message.
* [DebugInfo] Make describeLoadedValue() reg awareDavid Stenberg2019-12-094-3/+535
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the describeLoadedValue() hook is assumed to describe the value of the instruction's first explicit define. The hook will not be called for instructions with more than one explicit define. This commit adds a register parameter to the describeLoadedValue() hook, and invokes the hook for all registers in the worklist. This will allow us to for example describe instructions which produce more than two parameters' values; e.g. Hexagon's various combine instructions. This also fixes a case in our downstream target where we may pass smaller parameters in the high part of a register. If such a parameter's value is produced by a larger copy instruction, we can't describe the call site value using the super-register, and we instead need to know which sub-register that should be used. This also allows us to handle cases like this: $ebx = [...] $rdi = MOVSX64rr32 $ebx $esi = MOV32rr $edi CALL64pcrel32 @call The hook will first be invoked for the MOV32rr instruction, which will say that @call's second parameter (passed in $esi) is described by $edi. As $edi is not preserved it will be added to the worklist. When we get to the MOVSX64rr32 instruction, we need to describe two values; the sign-extended value of $ebx -> $rdi for the first parameter, and $ebx -> $edi for the second parameter, which is now possible. This commit modifies the dbgcall-site-lea-interpretation.mir test case. In the test case, the values of some 32-bit parameters were produced with LEA64r. Perhaps we can in general cases handle such by emitting expressions that AND out the lower 32-bits, but I have not been able to land in a case where a LEA64r is used for a 32-bit parameter instead of LEA64_32 from C code. I have not found a case where it would be useful to describe parameters using implicit defines, so in this patch the hook is still only invoked for explicit defines of forwarding registers.
* Attempt to fix a debuginfo test that wasn't as generic as I thoughtJeremy Morse2019-12-061-1/+1
| | | | | | | | | An ARM buildbot croaks when this test doesn't have a triple specified: http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/12021/ Move the test to the X86 directory and put an x86_64 triple on the llc command line.
* [DebugInfo][CGP] Update dbg.values when sinking address computationsJeremy Morse2019-12-061-0/+70
| | | | | | | | | | | | | | | | | One of CodeGenPrepare's optimizations is to duplicate address calculations into basic blocks, so that as much information as possible can be folded into memory addressing operands. This is great -- but the dbg.value variable location intrinsics are not updated in the same way. This can lead to dbg.values referring to address computations in other blocks that will never be encoded into the DAG, while duplicate address computations are performed locally that could be used by the dbg.value. Some of these (such as non-constant-offset GEPs) can't be salvaged past. Fix this by, whenever we duplicate an address computation into a block, looking for dbg.value users of the original memory address in the same block, and redirecting those to the local computation. Differential Revision: https://reviews.llvm.org/D58403
* [DebugInfo] Don't create multiple DBG_VALUEs when sinkingJeremy Morse2019-12-051-0/+106
| | | | | | | | | | | | | | | | | This patch addresses a performance problem reported in PR43855, and present in the reapplication in in 001574938e5. It turns out that MachineSink will (often) move instructions to the first block that post-dominates the current block, and then try to sink further. This means if we have a lot of conditionals, we can needlessly create large numbers of DBG_VALUEs, one in each block the sunk instruction passes through. To fix this, rather than immediately sinking DBG_VALUEs, record them in a pass structure. When sinking is complete and instructions won't be sunk any further, new DBG_VALUEs are added, avoiding lots of intermediate DBG_VALUE $noregs being created. Differential revision: https://reviews.llvm.org/D70676
* [DebugInfo] Don't reorder DBG_VALUEs when sunkJeremy Morse2019-12-051-1/+133
| | | | | | | | | | | | | | | | | | | | | | | Fix part of PR43855, resolving a problem that comes from the reapplication in 001574938e5. If we have two DBG_VALUE insts in a block that specify the location of the same variable, for example: %0 = someinst DBG_VALUE %0, !123, !DIExpression() %1 = anotherinst DBG_VALUE %1, !123, !DIExpression() if %0 were to sink, the corresponding DBG_VALUE would sink too, past the next DBG_VALUE, effectively re-ordering assignments. To fix this, I've added a SeenDbgVars set recording what variable locations have been seen in a block already (working bottom up), and now flag DBG_VALUEs that would pass a later DBG_VALUE for the same variable. NB, this only works for repeated DBG_VALUEs in the same basic block, the general case involving control flow is much harder, which I've written up in PR44117. Differential revision: https://reviews.llvm.org/D70672
* [DebugInfo] Re-apply two patches to MachineSinkJeremy Morse2019-12-053-0/+213
| | | | | | | | | | | | | These were: * D58386 / f5e1b718a67 / reverted in d382a8a768b * D58238 / ee50590e168 / reverted in a8db456b53a Of which the latter has a performance regression tracked in PR43855, fixed by D70672 / D70676, which will be committed atomically with this reapplication. Contains a minor difference to account for a change in the IsCopyInstr signature.
* [llvm/DWARF] Return section offset from DWARFUnit::get{Loc,Rng}listOffsetPavel Labath2019-12-053-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently these function return the raw content of the appropriate table header, which means they are relative to the DW_AT_{loc,rng}list_base, and one has to relocate them in order to do anything. This changes the functions to perform the relocation themselves, which seems more clearer, particularly as they are sitting right next to the find{Rng,Loc}listFromOffset functions, but one *cannot* simply take the result of these functions and take pass them there. The only effect of this patch is to change what value is dumped for the DW_AT_ranges attribute, which I think is for the better, as previously the values appeared to point into thin air. (The main reason I am looking at this is because I was trying to implement equivalent functionality in lldb's DWARFUnit, and was stumped by this behavior. Reviewers: dblaikie, JDevlieghere, aprantl Subscribers: hiraditya, llvm-commits, SouraVX Tags: #llvm Differential Revision: https://reviews.llvm.org/D71006
* [DebugInfo] Handle call site values for instructions before call bundleDavid Stenberg2019-12-051-0/+187
| | | | | | | | | | | | | | | | | | | | | | | Summary: If a call is bundled then the code that looks for instructions that produce parameter values would break when reaching the call's bundle header, due to the `ifCall(/*AnyInBundle*/)` invocation returning true. It is not enough to simply ignore bundle headers in the `isCall()` invocation, as the bundle header may have defines of parameter registers due to the call, meaning that such registers would incorrectly be removed from the worklist. Therefore, do not look at bundle headers at all. Reviewers: djtodoro, NikolaPrica, aprantl, vsk Reviewed By: aprantl, vsk Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D71024
* Reland "[LiveDebugValues] Introduce entry values of unmodified params"Djordje Todorovic2019-12-055-0/+677
| | | | Relanding this after resolving the cause of the test failure.
* [llvm-symbolizer] Support debug file lookup using build IDPetr Hosek2019-12-042-0/+28
| | | | | | | | | | | | | | | | | | | Build ID is a protocol for looking up debug files that's already supported by various tools including debuggers. For example, when locating debug files, gdb would check the following directories: - /usr/lib/debug/.build-id/ab/cdef1234.debug - /usr/bin/ls.debug - /usr/bin/.debug/ls.debug - /usr/lib/debug/usr/bin/ls.debug llvm-symbolizer currently consults all of these except for build ID based one. This patch implements support for build ID lookup. The set of debug directories to search is specified by the new option: --debug-file-directory, whose name matches the debug-file-directory variable used by gdb for the same purpose. Differential Revision: https://reviews.llvm.org/D70759
* [DWARF5][Debuginfo] Compilation unit type (DW_UT_skeleton) and root DIE ↵Alexey Lapshin2019-12-053-5/+5
| | | | | | | | | | | | | | | | | | | | (DW_TAG_compile_unit) do not match. That patch fixes incompatible compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_compile_unit) error. cat split-dwarf.cpp int main() { int a = 1; return 0; } clang++ -O -g -gsplit-dwarf -gdwarf-5 split-dwarf.cpp; llvm-dwarfdump --verify ./a.out | grep skeleton error: Compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_compile_unit) do not match. The fix is to change DW_TAG_compile_unit into DW_TAG_skeleton_unit when skeleton file is generated. Differential Revision: https://reviews.llvm.org/D70880
* Revert "[LiveDebugValues] Introduce entry values of unmodified params"Djordje Todorovic2019-12-035-677/+0
| | | | This reverts commit rG4cfceb910692 due to LLDB test failing.
* [DWARF] Add support for parsing/dumping section indices in location listsPavel Labath2019-12-031-8/+8
| | | | | | | | | | | | | | | | | | | Summary: This does exactly what it says on the box. The only small gotcha is the section index computation for offset_pair entries, which can use either the base address section, or the section from the offset_pair entry. This is to support both the cases where the base address is relocated (points to the base of the CU, typically), and the case where the base address is a constant (typically zero) and relocations are on the offsets themselves. Reviewers: dblaikie, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits, probinson Tags: #llvm Differential Revision: https://reviews.llvm.org/D70540
* [LiveDebugValues] Introduce entry values of unmodified paramsDjordje Todorovic2019-12-035-0/+677
| | | | | | | | | | | | | | | | | | | | | The idea is to remove front-end analysis for the parameter's value modification and leave it to the value tracking system. Front-end in some cases marks a parameter as modified even the line of code that modifies the parameter gets optimized, that implies that this will cover more entry values even. In addition, extending the support for modified parameters will be easier with this approach. Since the goal is to recognize if a parameter’s value has changed, the idea at very high level is: If we encounter a DBG_VALUE other than the entry value one describing the same variable (parameter), we can assume that the variable’s value has changed and we should not track its entry value any more. That would be ideal scenario, but due to various LLVM optimizations, a variable’s value could be just moved around from one register to another (and there will be additional DBG_VALUEs describing the same variable), so we have to recognize such situation (otherwise, we will lose a lot of entry values) and salvage the debug entry value. Differential Revision: https://reviews.llvm.org/D68209
* Recommit "[DWARF5]Addition of alignment atrribute in typedef DIE."Sourabh Singh Tomar2019-12-031-0/+63
| | | | | | | | | | | | | | | | This revision is revised to update Go-bindings and Release Notes. The original commit message follows. This patch, adds support for DW_AT_alignment[DWARF5] attribute, to be emitted with typdef DIE. When explicit alignment is specified. Patch by Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: aprantl, dblaikie, jini.susan.george, SouraVX, alok, deadalinx Differential Revision: https://reviews.llvm.org/D70111
* [DebugInfo] Support for debug_macinfo.dwo section in llvm and llvm-dwarfdump.Sourabh Singh Tomar2019-12-032-0/+20
| | | | | | | | | | | This patch adds support for debug_macinfo.dwo section[pre-standardized] to llvm and llvm-dwarfdump. Reviewers: probinson, dblaikie, aprantl, jini.susan.george, alok Differential Revision: https://reviews.llvm.org/D70705 Tags: #debug-info #llvm
* [Object][RISCV][test] Improve DebugInfo/RISCV/relax-debug-frame.llFangrui Song2019-11-261-14/+10
| | | | | | Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D70578
* [DebugInfo] Avoid register coalesing unsoundly changing DBG_VALUE locationsJeremy Morse2019-11-251-0/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a re-land of D56151 / r364515 with a completely new implementation. Once MIR code leaves SSA form and the liveness of a vreg is considered, DBG_VALUE insts are able to refer to non-live vregs, because their debug-uses do not contribute to liveness. This non-liveness becomes problematic for optimizations like register coalescing, as they can't ``see'' the debug uses in the liveness analyses. As a result registers get coalesced regardless of debug uses, and that can lead to invalid variable locations containing unexpected values. In the added test case, the first vreg operand of ADD32rr is merged with various copies of the vreg (great for performance), but a DBG_VALUE of the unmodified operand is blindly updated to the modified operand. This changes what value the variable will appear to have in a debugger. Fix this by changing any DBG_VALUE whose operand will be resurrected by register coalescing to be a $noreg DBG_VALUE, i.e. give the variable no location. This is an overapproximation as some coalesced locations are safe (others are not) -- an extra domination analysis would be required to work out which, and it would be better if we just don't generate non-live DBG_VALUEs. Differential Revision: https://reviews.llvm.org/D64630
* [DebugInfo@O2][Utils] Undef instead of delete dbg.values in helper funcOCHyams2019-11-251-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Related bug: https://bugs.llvm.org/show_bug.cgi?id=40648 Static helper function rewriteDebugUsers in Local.cpp deletes dbg.value intrinsics when it cannot move or rewrite them, or salvage the deleted instruction's value. It should instead undef them in this case. This patch fixes that and I've added a test which covers the failing test case in bz40648. I've updated the unit test Local.ReplaceAllDbgUsesWith to check for this behaviour (and fixed a typo in the test which would cause the old test to always pass). Reviewers: aprantl, vsk, djtodoro, probinson Reviewed By: vsk Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D70604
* [Object][RISCV] Resolve R_RISCV_32_PCRELLuís Marques2019-11-211-1/+2
| | | | | | | | | | | | | Summary: Add support for resolving `R_RISCV_32_PCREL` relocations. Those aren't actually resolved AFAIK, but support is still needed to avoid llvm-dwarfdump errors. The use of these relocations was introduced in D66419 but the corresponding resolving wasn't added then. The test adds a check that should catch future unresolved relocations. Reviewers: asb, lenary Reviewed By: asb Tags: #llvm Differential Revision: https://reviews.llvm.org/D70204
* Fix an offset underflow bug in DwarfExpression when describing small values ↵Adrian Prantl2019-11-201-0/+36
| | | | | | | | | | | | | | | | | | with subregisters DwarfExpression::addMachineReg() knows how to build a larger register that isn't expressible in DWARF by combining multiple subregisters. However, if the entire value fits into just one subregister, it would still emit the other subregisters, leading to all sorts of inconsistencies down the line. This patch fixes that by moving an already existing(!) check whether the subregister's offset is before the end of the value to the right place. rdar://problem/57294211 Differential Revision: https://reviews.llvm.org/D70508
* [DebugInfo] Remove the DIFlagArgumentNotModified debug info flagDjordje Todorovic2019-11-2014-30/+30
| | | | | | | Due to changes in D68206, we remove the DIFlagArgumentNotModified and its usage. Differential Revision: https://reviews.llvm.org/D68207
* [CGDebugInfo] Emit subprograms for decls when AT_tail_call is understood ↵Vedant Kumar2019-11-191-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (reland with fixes) Currently, clang emits subprograms for declared functions when the target debugger or DWARF standard is known to support entry values (DW_OP_entry_value & the GNU equivalent). Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU tail calls. Pre-patch debug session with a cross-TU tail call: ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` Post-patch (note that the tail-calling frame, "helper", is visible): ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f80 main`helper [opt] [artificial] frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` This was reverted in 5b9a072c because it attached declaration subprograms to inlinable builtin calls, which interacted badly with the MergeICmps pass. The fix is to not attach declarations to builtins. rdar://46577651 Differential Revision: https://reviews.llvm.org/D69743
* [DebugInfo] Describe size of spilled values in call site paramsVedant Kumar2019-11-191-1/+1
| | | | | | | | A call site parameter description of a memory operand needs to unambiguously convey the size of the operand to prevent incorrect entry value evaluation. Thanks for David Stenberg for pointing this issue out!
* Fix PR44001: assert failure in getFunctionLocalOffsetAfterInsnThomas Preud'homme2019-11-191-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Assert in getFunctionLocalOffsetAfterInsn() fails when processing a call MachineInstr inside a bundle and compiling with debug info. This is because labels are added by DwarfDebug::beginInstruction() which is called for each top-level MI by EmitFunctionBody()'s for-loop iteration but constructCallSiteEntryDIEs() which calls getFunctionLocalOffsetAfterInsn() iterates over all MIs. This commit modifies constructCallSiteEntryDIEs() to get the associated bundle MI for call MIs inside a bundle and use that to when calling getFunctionLocalOffsetAfterInsn() and getLabelAfterInsn(). It also skips loop iterations for bundle MIs since the loop statements are concerned with debug info for each physical instructions and bundles represent a group of instructions. It also fix the comment about PCAddr since the code is getting the return address and not the call address. Reviewers: dstenb, vsk, aprantl, djtodoro, dblaikie, NikolaPrica Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70293
* Revert "[DWARF5]Addition of alignment atrribute in typedef DIE."Sam McCall2019-11-181-63/+0
| | | | | This reverts commit 423f541c1a322963cf482683fe9777ef0692082d, which breaks llvm-c ABI.
* Re-commit "DWARF location lists: Add section index dumping"Pavel Labath2019-11-188-25/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies c0f6ad7d1f3ccb9d0b9ce9ef8dfa06409ccf1b3e with an additional fix in test/DebugInfo/X86/constant-loclist.ll, which had a slightly different output on windows targets. The test now accounts for this difference. The original commit message follows. Summary: As discussed in D70081, this adds the ability to dump section names/indices to the location list dumper. It does this by moving the range specific logic from DWARFDie.cpp:dumpRanges into the DWARFAddressRange class. The trickiest part of this patch is the backflip in the meanings of the two dump flags for the location list sections. The dumping of "raw" location list data is now controlled by "DisplayRawContents" flag. This frees up the "Verbose" flag to be used to control whether we print the section index. Additionally, the DisplayRawContents flag is set for section-based dumps whenever the --verbose option is passed, but this is not done for the "inline" dumps. Also note that the index dumping currently does not work for the DWARF v5 location lists, as the parser does not fill out the appropriate fields. This will be done in a separate patch. Reviewers: dblaikie, probinson, JDevlieghere, SouraVX Subscribers: sdardis, hiraditya, jrtc27, atanasyan, arphaman, aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70227
* Revert rGc0f6ad7d1f3c : "DWARF location lists: Add section index dumping"Simon Pilgrim2019-11-187-20/+20
| | | | This reverts commit c0f6ad7d1f3ccb9d0b9ce9ef8dfa06409ccf1b3e to fix the buildbots.
* DWARF location lists: Add section index dumpingPavel Labath2019-11-187-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in D70081, this adds the ability to dump section names/indices to the location list dumper. It does this by moving the range specific logic from DWARFDie.cpp:dumpRanges into the DWARFAddressRange class. The trickiest part of this patch is the backflip in the meanings of the two dump flags for the location list sections. The dumping of "raw" location list data is now controlled by "DisplayRawContents" flag. This frees up the "Verbose" flag to be used to control whether we print the section index. Additionally, the DisplayRawContents flag is set for section-based dumps whenever the --verbose option is passed, but this is not done for the "inline" dumps. Also note that the index dumping currently does not work for the DWARF v5 location lists, as the parser does not fill out the appropriate fields. This will be done in a separate patch. Reviewers: dblaikie, probinson, JDevlieghere, SouraVX Subscribers: sdardis, hiraditya, jrtc27, atanasyan, arphaman, aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70227
* [DWARF5]Addition of alignment atrribute in typedef DIE.Sourabh Singh Tomar2019-11-161-0/+63
| | | | | | | | | | | | This patch, adds support for DW_AT_alignment[DWARF5] attribute, to be emitted with typdef DIE. When explicit alignment is specified. Patch by Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: aprantl, dblaikie, jini.susan.george, SouraVX, alok, deadalinx Differential Revision: https://reviews.llvm.org/D70111
* DebugInfo: Templatize rnglist header parsing to setup for reuse with loclist ↵David Blaikie2019-11-152-2/+2
| | | | header parsing
* DWARFDebugLoc(v4): Add an incremental parsing functionPavel Labath2019-11-1511-26/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds a visitLocationList function to the DWARF v4 location lists, similar to what already exists for DWARF v5. It follows the approach outlined in previous patches (D69672), where the parsed form is always stored in the DWARF v5 format, which makes it easier for generic code to be built on top of that. v4 location lists are "upgraded" during parsing, and then this upgrade is undone while dumping. Both "inline" and section-based dumping is rewritten to reuse the existing "generic" location list dumper. This means that the output format is consistent for all location lists (the only thing one needs to implement is the function which prints the "raw" form of a location list), and that debug_loc dumping correctly processes base address selection entries, etc. The previous existing debug_loc functionality (e.g., parseOneLocationList) is rewritten on top of the new API, but it is not removed as there is still code which uses them. This will be done in follow-up patches, after I build the API to access the "interpreted" location lists in a generic way (as that is what those users really want). Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69847
* [DebugInfo] Allow spill slots in call site parameter descriptionsVedant Kumar2019-11-141-0/+177
| | | | | | | | | | | | | | | | | | | | | | Allow call site paramter descriptions to reference spill slots. Spill slots are not visible to high-level LLVM IR, so they can safely be referenced during entry value evaluation (as they cannot be clobbered by some other function). This gives a 5% increase in the number of call site parameter DIEs in an LTO x86_64 build of the xnu kernel. This reverts commit eb4c98ca3d2590bad9f6542afbf3a7824d2b53fa ( [DebugInfo] Exclude memory location values as parameter entry values), effectively reintroducing the portion of D60716 which dealt with memory locations (authored by Djordje, Nikola, Ananth, and Ivan). This partially addresses llvm.org/PR43343. However, not all memory operands forwarded to callees live in spill slots. In the xnu build, it may be possible to use an escape analysis to increase the number of call site parameter by another 15% (more details in PR43343). Differential Revision: https://reviews.llvm.org/D70254
* [RISCV] Fix wrong CFI directivesLuís Marques2019-11-141-3/+2
| | | | | | | | | | | | | Summary: Removes CFI CFA directives that could incorrectly propagate beyond the basic block they were inteded for. Specifically it removes the epilogue CFI directives. See the branch_and_tail_call test for an example of the issue. Should fix the stack unwinding issues caused by the incorrect directives. Reviewers: asb, lenary, shiva0217 Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D69723
* [AArch64][DebugInfo] Fix incorrect call site param value produced by MOVZXiDjordje Todorovic2019-11-141-0/+136
| | | | | | This resolves the problem with the truncation of the immediate operand. Differential Revision: https://reviews.llvm.org/D70168
* DWARFDebugLoclists: stricter base address handlingPavel Labath2019-11-141-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [DebugInfo] Avoid creating entry values for clobbered registersDavid Stenberg2019-11-131-0/+185
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Entry values are considered for parameters that have register-described DBG_VALUEs in the entry block (along with other conditions). If a parameter's value has been propagated from the caller to the callee, then the parameter's DBG_VALUE in the entry block may be described using a register defined by some instruction, and entry values should not be emitted for the parameter, which can currently occur. One such case was seen in the attached test case, in which the second parameter, which is described by a redefinition of the first parameter's register, would incorrectly get an entry value using the first parameter's register. This commit intends to solve such cases by keeping track of register defines, and ignoring DBG_VALUEs in the entry block that are described by such registers. In a RelWithDebInfo build of clang-8, the average size of the set was 27, and in a RelWithDebInfo+ASan build it was 30. Reviewers: djtodoro, NikolaPrica, aprantl, vsk Reviewed By: djtodoro, vsk Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D69889
* DWARFDebugLoclists: add location list "interpretation" logicPavel Labath2019-11-122-20/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Do not create a debug_macinfo section if no CUs have associated ↵David Blaikie2019-11-088-22/+15
| | | | | | macros Patch based on Sourabh Singh's D69839 patch.
* NVPTX: Don't insert an extra empty line at the end of the last section.David Blaikie2019-11-085-5/+0
| | | | | | | This was arbitrarily appearing in only the last section emitted - which made tests more sensitive than they needed to be (removing the last section - like the macinfo section change that's coming after this) would, surprisingly, move the blank line to the previous section.
* DebugInfo: Use separate macinfo contributions for each CUDavid Blaikie2019-11-087-13/+13
| | | | | | | | | | | | | | | | 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.
* Revert d91ed80 "[codeview] Reference types in type parent scopes"Hans Wennborg2019-11-082-135/+2
| | | | | | | | | | | | | | | | | | | This triggered asserts in the Chromium build, see https://crbug.com/1022729 for details and reproducer. > Without this change, when a nested tag type of any kind (enum, class, > struct, union) is used as a variable type, it is emitted without > emitting the parent type. In CodeView, parent types point to their inner > types, and inner types do not point back to their parents. We already > walk over all of the parent scopes to build the fully qualified name. > This change simply requests their type indices as we go along to enusre > they are all emitted. > > Fixes PR43905 > > Reviewers: akhuang, amccarth > > Differential Revision: https://reviews.llvm.org/D69924
* [codeview] Reference types in type parent scopesReid Kleckner2019-11-072-2/+135
| | | | | | | | | | | | | | | | Without this change, when a nested tag type of any kind (enum, class, struct, union) is used as a variable type, it is emitted without emitting the parent type. In CodeView, parent types point to their inner types, and inner types do not point back to their parents. We already walk over all of the parent scopes to build the fully qualified name. This change simply requests their type indices as we go along to enusre they are all emitted. Fixes PR43905 Reviewers: akhuang, amccarth Differential Revision: https://reviews.llvm.org/D69924
* Revert a5c8ec4 "[CGDebugInfo] Emit subprograms for decls when AT_tail_call ↵Hans Wennborg2019-11-071-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | is understood" This caused Chromium builds to fail with "inlinable function call in a function with debug info must have a !dbg location" errors. See https://bugs.chromium.org/p/chromium/issues/detail?id=1022296#c1 for a reproducer. > Currently, clang emits subprograms for declared functions when the > target debugger or DWARF standard is known to support entry values > (DW_OP_entry_value & the GNU equivalent). > > Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU > tail calls. > > Pre-patch debug session with a cross-TU tail call: > > ``` > * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] > frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt] > ``` > > Post-patch (note that the tail-calling frame, "helper", is visible): > > ``` > * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] > frame #1: 0x0000000100000f80 main`helper [opt] [artificial] > frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt] > ``` > > rdar://46577651 > > Differential Revision: https://reviews.llvm.org/D69743
* DWARFDebugLoclists: Move to a incremental parsing modelPavel Labath2019-11-064-26/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CGDebugInfo] Emit subprograms for decls when AT_tail_call is understoodVedant Kumar2019-11-041-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, clang emits subprograms for declared functions when the target debugger or DWARF standard is known to support entry values (DW_OP_entry_value & the GNU equivalent). Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU tail calls. Pre-patch debug session with a cross-TU tail call: ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` Post-patch (note that the tail-calling frame, "helper", is visible): ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f80 main`helper [opt] [artificial] frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` rdar://46577651 Differential Revision: https://reviews.llvm.org/D69743
* [test][DebugInfo] Add the test for ARM call site parametersDjordje Todorovic2019-10-311-0/+171
| | | | | | This is addition to D67556. Patch by Nikola Prica
* Revert "[DebugInfo] MachineSink: Insert undef DBG_VALUEs when sinking ↵Jeremy Morse2019-10-312-108/+0
| | | | | | | | | instructions" This reverts commit ee50590e1684c197bc4336984795e48bf53c7a4e. PR43855 reports a performance regression from this commit, which I'll look into.
* Revert "[DebugInfo] MachineSink: find more DBG_VALUEs to sink"Jeremy Morse2019-10-311-105/+0
| | | | | | | This reverts commit f5e1b718a675a4449b71423f04d38e1e93045105. PR43855 reports a performance regression with commit ee50590e. This commit depends on the faulty one, so has to come out too.
OpenPOWER on IntegriCloud