summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
* [globalopt] Don't emit DWARF fragments for membersDavid Spickett2020-05-181-0/+69
| | | | | | | | | | | | | | | | of a struct that cover the whole struct This can happen when the rest of the members of are zero length. Following the same pattern applied to the SROA pass in: d7f6f1636d53c3e2faf55cdf20fbb44a1a149df1 Fixes: https://bugs.llvm.org/show_bug.cgi?id=45335 Differential Revision: https://reviews.llvm.org/D78720 (cherry picked from commit 3929429347d398773577b79f7fdb780d4f7ed887)
* Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field"Jeremy Morse2020-02-1212-56/+30
| | | | | | | | | | | | | | | | | | | | | | | This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref. (cherry picked from commit 6531a78ac4b5b229bce272706593a0bc873877d7)
* Revert "[DebugInfo][DAG] Distinguish different kinds of location indirection"Jeremy Morse2020-02-121-85/+0
| | | | | | | | | | | | | | This reverts commit 3137fe4d23eeb8df08c03e9111465325eeafe08e. I'm backing out D68945, which this patch is a follow up for. It'll be re-landed when D68945 is fixed. The changes to dbg-value-func-arg.ll occur because our handling of certain kinds of location now mixes up indirection that happens at different points in a DIExpression. While this is a regression, it's a return to the prior behaviour while a better patch is sought. (cherry picked from commit ece761427f63de96ee52bbd6be1c61b07967a917)
* [DebugInfo] Re-instate LiveDebugVariables scope trimmingJeremy Morse2020-02-122-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch reverts part of r362750 / D62650, which stopped LiveDebugVariables from trimming leading variable location ranges down to only covering those instructions that are in scope. I've observed some circumstances where the number of DBG_VALUEs in a function can be amplified in an un-necessary way, to cover more instructions that are out of scope, leading to very slow compile times. Trimming the range of instructions that the variables cover solves the slow compile times. The specific problem that r362750 tries to fix is addressed by the assignment to RStart that I've added. Any variable location that begins at the first instruction of a block will now be considered to begin at the start of the block. While these sound the same, the have different SlotIndexes, and the register allocator may shoehorn additional instructions in between the two. The test added in the past (wrong_debug_loc_after_regalloc.ll) still works with this modification. live-debug-variables.ll has a range trimmed to not cover the prologue of the function, while dbg-addr-dse.ll has a DBG_VALUE sink past one instruction with no DebugLoc, which is expected behaviour. Differential Revision: https://reviews.llvm.org/D73691 (cherry picked from commit 41206b61e30c3d84188cb17b91c2c0c800982dd1)
* Revert "Reland: [DWARF] Allow cross-CU references of subprogram definitions"Vedant Kumar2020-01-294-267/+12
| | | | | | | | | | | | | | | ... as well as: Revert "[DWARF] Defer creating declaration DIEs until we prepare call site info" This reverts commit fa4701e1979553c2df61698ac1ac212627630442. This reverts commit 79daafc90308787b52a5d3a7586e82acd5e374b3. There have been reports of this assert getting hit: CalleeDIE && "Could not find DIE for call site entry origin (cherry picked from commit 802bec896171997a7b73dde3857712e0eedeabc1)
* [DebugInfo][test] Change two MIR tests to use -start-before=livedebugvalues ↵Fangrui Song2020-01-242-4/+4
| | | | | | | | instead of -start-after=patchable-function To break order dependency between livedebugvalues and patchable-function. (cherry picked from commit 26ba1f77b55e7a961acc05d94bfa4b677a9e5d83)
* [DBG][LIVEDEBUGVALUES][NFC] Add Targeted LiveDebugValues Behaviour Tests.Tom Weaver2020-01-1422-0/+1546
| | | | | | | | | Adds 22 distinct tests that exercise the live-debug-values passes expected behaviour. reviewers: aprantl, vsk Differential revision: https://reviews.llvm.org/D72515
* Revert "[DBG][LIVEDEBUGVALUES][NFC] Add Targeted LiveDebugValues Behaviour ↵Tom Weaver2020-01-1422-1546/+0
| | | | | | Tests." This reverts commit 35787e3a062a4a21c145137552d20cb1169c74fc.
* [DBG][LIVEDEBUGVALUES][NFC] Add Targeted LiveDebugValues Behaviour Tests.Tom Weaver2020-01-1422-0/+1546
| | | | | | | | | Adds 22 distinct tests that exercise the live-debug-values passes expected behaviour. reviewers: aprantl, vsk Differential revision: https://reviews.llvm.org/D72515
* Revert "[DWARF5][DebugInfo]: Added support for DebugInfo generation for auto ↵Amy Huang2020-01-131-70/+0
| | | | | | | return type for C++ member functions." This reverts commit c958639098a8702b831952b1a1a677ae19190a55, which causes a crash. See https://reviews.llvm.org/D70524 for details.
* [MIPS][ELF] Use PC-relative relocations in .eh_frame when possibleAlex Richardson2020-01-131-3/+4
| | | | | | | | | | | | | | | | | | | | When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
* [DWARF5][DebugInfo]: Added support for DebugInfo generation for auto return ↵Awanish Pandey2020-01-131-0/+70
| | | | | | | | | | | | | | | | | | type for C++ member functions. Summary: This patch will provide support for auto return type for the C++ member functions. Before this return type of the member function is deduced and stored in the DIE. This patch includes llvm side implementation of this feature. Patch by: Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: dblaikie, aprantl, shafik, alok, SouraVX, jini.susan.george Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D70524
* llc: Change behavior of -mcpu with existing attributeMatt Arsenault2020-01-072-2/+2
| | | | | | | | | | | Don't overwrite existing target-cpu attributes. I've often found the replacement behavior annoying, and this is inconsistent with how the fast math command line flags interact with the function attributes. Does not yet change target-features, since I think that should behave as a concatenation.
* Revert "DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode ↵David Blaikie2019-12-301-1/+1
| | | | | | | | | | | | serialization/deserialization" Seeing some curious CFI failures internally - which makes little sense to me, as I don't think anyone is using this flag (even us, internally)... so sounds like a bug in my code somewhere (possibly a latent one that propagating this flag exposed, not sure). Reverting while I investigate. This reverts commit c51b45e32ef7f35c11891f60871aa9c2c04cd991.
* DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode ↵David Blaikie2019-12-271-1/+1
| | | | | | serialization/deserialization Follow-up to r346788 review feedback from Adrian Prantl.
* [DebugInfo][SelectionDAG] Change order while transferring SDDbgValue to ↵Kristina Bessonova2019-12-261-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | another node SelectionDAG::transferDbgValues() can 'reattach' SDDbgValue from one to another node, but doesn't change its source order. If the destination node has the order greater than the SDDbgValue, there are two possible issues revealed later: * If debug info is attached to an instruction that is the first definition of a register, this ends up with a def-after-use and the debug info gets 'undef' later. * If MIR has another definition of a register above the debug info, the debug info may represent a source variable incorrectly because it appears (significantly) before an instruction corresponded to this debug info. So, the patch changes the order of an SDDbgValue when it is moved to a node with greater order. Reviewers: dblaikie, jmorse, aprantl Reviewed By: aprantl Subscribers: aprantl, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71175
* Migrate function attribute "no-frame-pointer-elim"="false" to ↵Fangrui Song2019-12-2482-150/+150
| | | | "frame-pointer"="none" as cleanups after D56351
* Migrate function attribute "no-frame-pointer-elim-non-leaf" to ↵Fangrui Song2019-12-247-9/+9
| | | | "frame-pointer"="non-leaf" as cleanups after D56351
* Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" ↵Fangrui Song2019-12-2483-117/+117
| | | | as cleanups after D56351
* DebugInfo: Correct the form of DW_AT_macro_info in .dwo files (sec_offset, ↵David Blaikie2019-12-241-1/+1
| | | | rather than data4)
* [DebugInfo] Fix v4 macinfo for dwo files.Sourabh Singh Tomar2019-12-241-0/+5
| | | | | Dwo files must contain have DW_AT_macro_info attribute, when macro information is emitted. Adjusted the test case for the same.
* [DWARF] Check that all fields of a Unit Header are read.Igor Kudrin2019-12-243-0/+31
| | | | | | | | | Tests "dwarfdump-rnglists-dwarf64.s" and "dwarfdump-rnglists.s" were malformed because they had missing required DWO ID fields in split compilation unit headers. The patch fixes the tests and checks the reading of a unit header more thoroughly. Differential Revision: https://reviews.llvm.org/D71704
* [DWARF] Defer creating declaration DIEs until we prepare call site infoVedant Kumar2019-12-203-24/+12
| | | | | | | | It isn't necessary to create DIEs for all of the declaration subprograms in a CU's retainedTypes list. We can defer creating these subprograms until we need to prepare a call site tag that refers to one. This cleanup was mentioned in passing in D70350.
* Reland: [DWARF] Allow cross-CU references of subprogram definitionsVedant Kumar2019-12-202-0/+267
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows a call site tag in CU A to reference a callee DIE in CU B without resorting to creating an incomplete duplicate DIE for the callee inside of CU A. We already allow cross-CU references of subprogram declarations, so it doesn't seem like definitions ought to be special. This improves entry value evaluation and tail call frame synthesis in the LTO setting. During LTO, it's common for cross-module inlining to produce a call in some CU A where the callee resides in a different CU, and there is no declaration subprogram for the callee anywhere. In this case llvm would (unnecessarily, I think) emit an empty DW_TAG_subprogram in order to fill in the call site tag. That empty 'definition' defeats entry value evaluation etc., because the debugger can't figure out what it means. As a follow-up, maybe we could add a DWARF verifier check that a DW_TAG_subprogram at least has a DW_AT_name attribute. Update: Reland with a fix to create a declaration DIE when the declaration is missing from the CU's retainedTypes list. The declaration is left out of the retainedTypes list in two cases: 1) Re-compiling pre-r266445 bitcode (in which declarations weren't added to the retainedTypes list), and 2) Doing LTO function importing (which doesn't update the retainedTypes list). It's possible to handle (1) and (2) by modifying the retainedTypes list (in AutoUpgrade, or in the LTO importing logic resp.), but I don't see an advantage to doing it this way, as it would cause more DWARF to be emitted compared to creating the declaration DIEs lazily. Tested with a stage2 ThinLTO+RelWithDebInfo build of clang, and with a ReleaseLTO-g build of the test suite. rdar://46577651, rdar://57855316, rdar://57840415 Differential Revision: https://reviews.llvm.org/D70350
* [WebAssembly] Use TargetIndex operands in DbgValue to track WebAssembly ↵Yury Delendik2019-12-202-0/+144
| | | | | | | | | | | | | | | | | | operands locations Extends DWARF expression language to express locals/globals locations. (via target-index operands atm) (possible variants are: non-virtual registers or address spaces) The WebAssemblyExplicitLocals can replace virtual registers to targertindex operand type at the time when WebAssembly backend introduces {get,set,tee}_local instead of corresponding virtual registers. Reviewed By: aprantl, dschuff Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D52634
* Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysrootAdrian Prantl2019-12-203-4/+4
| | | | | | | | | | | | This is a purely cosmetic change that is NFC in terms of the binary output. I bugs me that I called the attribute DW_AT_LLVM_isysroot since the "i" is an artifact of GCC command line option syntax (-isysroot is in the category of -i options) and doesn't carry any useful information otherwise. This attribute only appears in Clang module debug info. Differential Revision: https://reviews.llvm.org/D71722
* llvm-symbolizer: support DW_FORM_loclistx locations.Evgenii Stepanov2019-12-201-0/+305
| | | | | | | | | | | | | | | | Summary: With -gdwarf-5 local variable locations are emitted as DW_FORM_loclistx form instead of the regular DW_FORM_sec_offset. Teach DWARFDie::getLocations to understand the new format and use it in llvm-symbolizer "FRAME" command. Reviewers: pcc, jdoerfert Subscribers: srhines, aprantl, hiraditya, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70756
* [OPT-DBG] Teach DbgEntityHistoryCalculator about meta-instructions.Tom Weaver2019-12-204-4/+162
| | | | | | | | | | | | | | The calculator was considering instructions such as KILLs as clobbers of a physical address. This is wrong as meta instructions such as KILLs produce no output in the final program and thus don't clobber or change any physical location's value. As a result they're safe to ignore whilst calculating location list ranges. reviewers: aprantl, vsk diff revision: https://reviews.llvm.org/D70497 fixes: https://bugs.llvm.org/show_bug.cgi?id=38753
* DebugInfo: Fix test fallout from aaa5a5e7ff1aee632aae75311e7c044f710dd0a0David Blaikie2019-12-181-3/+3
|
* DebugInfo: Include DW_AT_base_addr even in gmlt with no inline functionsDavid Blaikie2019-12-181-0/+36
| | | | | | | | | Since the address pool doesn't get populated in this case (due to the lack of inlining, no child DIEs are added to the CU - so no addresses are needed for the DIEs themselves) until the range list is emitted - at the time the attributes are added to the CU, the address pool is empty. So check whether the address pool will be used for the range lists & add an addr_base if that's the case.
* Reapply: [DebugInfo] Correctly handle salvaged casts and split fragments at ISelstozer2019-12-182-2/+27
| | | | | | | | This reverts commit 1f3dd83cc1f2b8f72b9d59e2b4221b12fb7f9a95, reapplying commit bb1b0bc4e57428ce364d3d6c075ff03cb8973462. The original commit failed on some builds seemingly due to the use of a bracketed constructor with an std::array, i.e. `std::array<> arr({...})`.
* Revert "[DebugInfo] Correctly handle salvaged casts and split fragments at ISel"stozer2019-12-182-27/+2
| | | | | | Reverted due to build failure on windows bots. This reverts commit bb1b0bc4e57428ce364d3d6c075ff03cb8973462.
* [DebugInfo] Correctly handle salvaged casts and split fragments at ISelstozer2019-12-182-2/+27
| | | | | | | | | | | | | | | Previously, LLVM had no functional way of performing casts inside of a DIExpression(), which made salvaging cast instructions other than Noop casts impossible. This patch enables the salvaging of casts by using the DW_OP_LLVM_convert operator for SExt and Trunc instructions. There is another issue which is exposed by this fix, in which fragment DIExpressions (which are preserved more readily by this patch) for values that must be split across registers in ISel trigger an assertion, as the 'split' fragments extend beyond the bounds of the fragment DIExpression causing an error. This patch also fixes this issue by checking the fragment status of DIExpressions which are to be split, and dropping fragments that are invalid.
* Recommit "[DebugInfo] Refactored macro related generation,Sourabh Singh Tomar2019-12-181-0/+80
| | | | | | | | | | | | | | | | | | added a test case for macinfo.dwo emission." This was reverted in caa412090666c10f854322cdc701c1cbf8ed726e, since it was causing an assertion failure on Windows bots. This revision is revised to fix that. Original commit message - [DebugInfo] Refactored macro related generation, added a test case for macinfo.dwo emission. Reviewers: dblaikie, aprantl, jini.susan.george Tags: #debug-info #llvm Differential Revision: https://reviews.llvm.org/D71008
* [ObjC][DWARF] Emit DW_AT_APPLE_objc_direct for methods marked as ↵Raphael Isemann2019-12-171-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | __attribute__((objc_direct)) Summary: With DWARF5 it is no longer possible to distinguish normal methods and methods with `__attribute__((objc_direct))` by just looking at the debug information as they are both now children of the of the DW_TAG_structure_type that defines them (before only the `__attribute__((objc_direct))` methods were children). This means that in LLDB we are no longer able to create a correct Clang AST of a module by just looking at the debug information. Instead we would need to call the Objective-C runtime to see which of the methods have a `__attribute__((objc_direct))` and then add the attribute to our own Clang AST depending on what the runtime returns. This would mean that we either let the module AST be dependent on the Objective-C runtime (which doesn't seem right) or we retroactively add the missing attribute to the imported AST in our expressions. A third option is to annotate methods with `__attribute__((objc_direct))` as `DW_AT_APPLE_objc_direct` which is what this patch implements. This way LLDB doesn't have to call the runtime for any `__attribute__((objc_direct))` method and the AST in our module will already be correct when we create it. Reviewers: aprantl, SouraVX Reviewed By: aprantl Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D71201
* [BasicBlockUtils] Fix dbg.value elimination problem in MergeBlockIntoPredecessorBjorn Pettersson2019-12-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In commit d60f34c20a2f31335c8d5626e (llvm-svn 317128, PR35113) MergeBlockIntoPredecessor was changed into discarding some dbg.value intrinsics referring to PHI values, post-splice due to loop rotation. That elimination of dbg.value intrinsics did not consider which dbg.value to keep depending on the context (e.g. if the variable is changing its value several times inside the basic block). In the past that hasn't been such a big problem since CodeGenPrepare::placeDbgValues has moved the dbg.value to be next to the PHI node anyway. But after commit 00e238896cd8ad3a7d7 CodeGenPrepare isn't doing that any longer, so we need to be more careful when avoiding duplicate dbg.value intrinsics in MergeBlockIntoPredecessor. This patch replaces the code that tried to avoid duplicate dbg.values by using the RemoveRedundantDbgInstrs helper. Reviewers: aprantl, jmorse, vsk Reviewed By: aprantl, vsk Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71480
* [AArch64] Save FP for leaf functions when disabling frame pointer eliminationFangrui Song2019-12-131-1/+1
| | | | | | | | | | The change allows clang -mno-omit-leaf-frame-pointer to disable frame pointer elimination. This behavior matches X86 and Mips, and also GCC AArch64. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D71168
* [LiveDebugValues] Omit entry values for DBG_VALUEs with pre-existing expressionsDavid Stenberg2019-12-131-0/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a quickfix for PR44275. An assertion that checks that the DIExpression is valid failed due to attempting to create an entry value for an indirect parameter. This started appearing after D69028, as the indirect parameter started being represented using an DW_OP_deref, rather than with the DBG_VALUE's second operand, meaning that the isIndirectDebugValue() check in LiveDebugValues did not exclude such parameters. A DIExpression that has an entry value operation can currently not have any other operation, leading to the failed isValid() check. This patch simply makes us stop considering emitting entry values for such parameters. To support such cases I think we at least need to do the following changes: * In DIExpression::isValid(): Remove the limitation that a DW_OP_LLVM_entry_value operation can be the only operation in a DIExpression. * In LiveDebugValues::emitEntryValues(): Create an entry value of size 1, so that it only wraps the register operand, and not the whole pre-existing expression (the DW_OP_deref). * In LiveDebugValues::removeEntryValue(): Check that the new debug value has the same debug expression as the original, rather than checking that the debug expression is empty. * In DwarfExpression::addMachineRegExpression(): Modify the logic so that a DW_OP_reg* expression is emitted for the entry value. That is how GCC emits entry values for indirect parameters. That will currently not happen to due the DW_OP_deref causing the !HasComplexExpression to fail. The LocationKind needs to be changed also, rather than always emitting a DW_OP_stack_value for entry values. There are probably more things I have missed, but that could hopefully be a good starting point for emitting such entry values. Reviewers: djtodoro, aprantl, jmorse, vsk Reviewed By: aprantl, vsk Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D71416
* [DWARF5][DWARFVerifier] Check that Skeleton compilation unit does not have ↵Alexey Lapshin2019-12-121-0/+47
| | | | | | | | | children. That patch adds checking into DWARFVerifier that the Skeleton compilation unit does not have children. Differential Revision: https://reviews.llvm.org/D71244
* Revert "[DWARF] Allow cross-CU references of subprogram definitions"Vedant Kumar2019-12-111-223/+0
| | | | | | | | | This reverts commit 30038da15b18ac4e34b9ea7a648382ae481e4770. It causes the stage2 thinLTO bot to fail with: Assertion failed: (CU.getDIE(CalleeSP) && "Expected declaration subprogram DIE for callee") rdar://57840415
* Revert "[DebugInfo] Refactored macro related generation, added a test case ↵Nico Weber2019-12-101-80/+0
| | | | | | | | | | | | | | | | for macinfo.dwo emission." This reverts commit 307f60a1a3ff04313a75e2fc11bc14df4fc2ffb8. DebugInfo/X86/debug-macinfo-split-dwarf.ll fails on Windows: Command Output (stdout): -- $ ":" "RUN: at line 1" $ "c:\src\llvm-project\out\gn\bin\llc.exe" "-mtriple=x86_64-pc-windows-gnu" "-O0" "-split-dwarf-file=foo.dwo" "-filetype=obj" Assertion failed: Section && "Cannot switch to a null section!", file ../../llvm/lib/MC/MCStreamer.cpp, line 1103 Stack dump: 0. Program arguments: c:\src\llvm-project\out\gn\bin\llc.exe -mtriple=x86_64-pc-windows-gnu -O0 -split-dwarf-file=foo.dwo -filetype=obj
* [DWARF] Allow cross-CU references of subprogram definitionsVedant Kumar2019-12-101-0/+223
| | | | | | | | | | | | | | | | | | | | | | | | | This allows a call site tag in CU A to reference a callee DIE in CU B without resorting to creating an incomplete duplicate DIE for the callee inside of CU A. We already allow cross-CU references of subprogram declarations, so it doesn't seem like definitions ought to be special. This improves entry value evaluation and tail call frame synthesis in the LTO setting. During LTO, it's common for cross-module inlining to produce a call in some CU A where the callee resides in a different CU, and there is no declaration subprogram for the callee anywhere. In this case llvm would (unnecessarily, I think) emit an empty DW_TAG_subprogram in order to fill in the call site tag. That empty 'definition' defeats entry value evaluation etc., because the debugger can't figure out what it means. As a follow-up, maybe we could add a DWARF verifier check that a DW_TAG_subprogram at least has a DW_AT_name attribute. rdar://46577651 Differential Revision: https://reviews.llvm.org/D70350
* [DebugInfo] Refactored macro related generation, added a test case for ↵Sourabh Singh Tomar2019-12-111-0/+80
| | | | | | | | | | macinfo.dwo emission. Reviewers: dblaikie, aprantl, jini.susan.george Tags: #debug-info #llvm Differential Revision: https://reviews.llvm.org/D71008
* Recommit "[DWARF5] Start emitting DW_AT_dwo_name when -gdwarf-5 is specified."Sourabh Singh Tomar2019-12-112-2/+2
| | | | | | | | Reviewers: dblaikie, aprantl, probinson Tags: #debug-info #llvm Differential Revision: https://reviews.llvm.org/D71185
* Revert "[DWARF5] Start emitting DW_AT_dwo_name when -gdwarf-5 is specified."Sourabh Singh Tomar2019-12-112-2/+2
| | | | | This reverts commit 6ef01588f4d75ef43da4ed2a37ba7a8b8daab259. Missing Differetial revision.
* [DWARF5] Start emitting DW_AT_dwo_name when -gdwarf-5 is specified.Sourabh Singh Tomar2019-12-112-2/+2
|
* Revert 30e8f80fd5a4 "[DebugInfo] Don't create multiple DBG_VALUEs when sinking"Hans Wennborg2019-12-101-106/+0
| | | | | | | | | | | | | | | | | | | | This caused non-determinism in the compiler, see command on the Phabricator code review. > 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] Nerf placeDbgValues, with prejudiceJeremy Morse2019-12-095-42/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CodeGenPrepare::placeDebugValues moves variable location intrinsics to be immediately after the Value they refer to. This makes tracking of locations very easy; but it changes the order in which assignments appear to the debugger, from the source programs order to the order in which the optimised program computes values. This then leads to PR43986 and PR38754, where variable locations that were in a conditional block are made unconditional, which is highly misleading. This patch adjusts placeDbgValues to only re-order variable location intrinsics if they use a Value before it is defined, significantly reducing the damage that it does. This is still not 100% safe, but the rest of CodeGenPrepare needs polishing to correctly update debug info when optimisations are performed to fully fix this. This will probably break downstream debuginfo tests -- if the instruction-stream position of variable location changes isn't the focus of the test, an easy fix should be to manually apply placeDbgValues' behaviour to the failing tests, moving dbg.value intrinsics next to SSA variable definitions thus: %foo = inst1 %bar = ... %baz = ... void call @llvm.dbg.value(metadata i32 %foo, ... to %foo = inst1 void call @llvm.dbg.value(metadata i32 %foo, ... %bar = ... %baz = ... This should return your test to exercising whatever it was testing before. Differential Revision: https://reviews.llvm.org/D58453
* [test][tools] Add missing and improve testingJames Henderson2019-12-091-0/+2
| | | | | | | | | | | Mostly this adds testing for certain aliases in more explicit ways. There are also a few tidy-ups, and additions of missing testing, where the feature was either not tested at all, or not tested explicitly and sufficiently. Reviewed by: MaskRay, rupprecht, grimar Differential Revision: https://reviews.llvm.org/D71116
* [DebugInfo] Make describeLoadedValue() reg awareDavid Stenberg2019-12-094-3/+535
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: 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 situations 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. Reviewers: djtodoro, NikolaPrica, aprantl, vsk Reviewed By: djtodoro, vsk Subscribers: ormris, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D70431
OpenPOWER on IntegriCloud