summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* Update testcase since llvm-dwarfdump got more accurate in r355148.Adrian Prantl2019-02-281-1/+1
| | | | llvm-svn: 355150
* [DebugInfo] Apply subprogram attributes on behalf of owner CUEugene Leviant2019-02-271-0/+92
| | | | | | | | | | | | When using full LTO it is possible that template function definition DIE is bound to one compilation unit and it's declaration to another. We should add function declaration attributes on behalf of its owner CU otherwise we may end up with malformed file identifier in function declaration DW_AT_decl_file attribute. Differential revision: https://reviews.llvm.org/D58538 llvm-svn: 354978
* [CodeView] Emit HasConstructorOrDestructor class option for non-trivial ↵Aaron Smith2019-02-263-11/+1023
| | | | | | | | | | | | | | | | constructors Reviewers: zturner, rnk, llvm-commits, aleksandr.urakov Reviewed By: zturner, rnk Subscribers: jdoerfert, majnemer, asmith Tags: #llvm Differential Revision: https://reviews.llvm.org/D44406 llvm-svn: 354841
* Revert r354244 "[DAGCombiner] Eliminate dead stores to stack."Clement Courbet2019-02-182-5/+38
| | | | | | Breaks some bots. llvm-svn: 354245
* [DAGCombiner] Eliminate dead stores to stack.Clement Courbet2019-02-182-38/+5
| | | | | | | | | | | | | | | Summary: A store to an object whose lifetime is about to end can be removed. See PR40550 for motivation. Reviewers: niravd Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D57541 llvm-svn: 354244
* [DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEsJeremy Morse2019-02-132-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | In this patch SelectionDAG tries to salvage any dbg.values that are going to be dropped, in case they can be recovered from Values in the current BB. It also strengthens SelectionDAGs handling of dangling debug data, so that dbg.values are *always* emitted (as Undef or otherwise) instead of dangling forever. The motivation behind this patch exists in the new test case: a memory address (here a bitcast and GEP) exist in one basic block, and a dbg.value referring to the address is left in the 'next' block. The base pointer is live across all basic blocks. In current llvm trunk the dbg.value cannot be encoded, and it isn't even emitted as an Undef DBG_VALUE. The change is simply: if we're definitely going to drop a dbg.value, repeatedly apply salvageDebugInfo to its operand until either we find something that can be encoded, or we can't salvage any further in which case we produce an Undef DBG_VALUE. To know when we're "definitely going to drop a dbg.value", SelectionDAG signals SelectionDAGBuilder when all IR instructions have been encoded to force salvaging. This ensures that any dbg.value that's dangling after DAG creation will have a corresponding DBG_VALUE encoded. Differential Revision: https://reviews.llvm.org/D57694 llvm-svn: 353954
* [DebugInfo][DAG] Limit special-casing of dbg.values for ArgumentsJeremy Morse2019-02-131-0/+104
| | | | | | | | | | | | | | | | | | | | | SelectionDAGBuilder has special handling for dbg.value intrinsics that are understood to define the location of function parameters on entry to the function. To enable this, we avoid recording a dbg.value as a virtual register reference if it might be such a parameter, so that it later hits EmitFuncArgumentDbgValue. This patch reduces the set of circumstances where we avoid recording a dbg.value as a virtual register reference, to allow more "normal" variables to be recorded that way. We now only bypass for potential parameters if: * The dbg.value operand is an Argument, * The Variable is a parameter, and * The Variable is not inlined. meaning it's very likely that the dbg.value is a function-entry parameter location. Differential Revision: https://reviews.llvm.org/D57584 llvm-svn: 353948
* [DebugInfo] Stop changing labels for register-described parameter DBG_VALUEsDavid Stenberg2019-02-1310-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to D57510. This patch stops DebugHandlerBase from changing the starting label for the first non-overlapping, register-described parameter DBG_VALUEs to the beginning of the function. That code did not consider what defined the registers, which could result in the ranges for the debug values starting before their defining instructions. We currently do not emit debug values for constant values directly at the start of the function, so this code is still useful for such values, but my intention is to remove the code from DebugHandlerBase completely when we get there. One reason for removing it is that the code violates the history map's ranges, which I think can make it quite confusing when troubleshooting. In D57510, PrologEpilogInserter was amended so that parameter DBG_VALUEs now are kept at the start of the entry block, even after emission of prologue code. That was done to reduce the degradation of debug completeness from this patch. PR40638 is another example, where the lexical-scope trimming that LDV does, in combination with scheduling, results in instructions after the prologue being left without locations. There might be other cases where the DBG_VALUEs are pushed further down, for which the DebugHandlerBase code may be helpful, but as it now quite often result in incorrect locations, even after the prologue, it seems better to remove that code, and try to work our way up with accurate locations. In the long run we should maybe not aim to provide accurate locations inside the prologue. Some single location descriptions, at least those referring to stack values, generate inaccurate values inside the epilogue, so we maybe should not aim to achieve accuracy for location lists. However, it seems that we now emit line number programs that can result in GDB and LLDB stopping inside the prologue when doing line number stepping into functions. See PR40188 for more information. A summary of some of the changed test cases is available in PR40188#c2. Reviewers: aprantl, dblaikie, rnk, jmorse Reviewed By: aprantl Subscribers: jdoerfert, jholewinski, jvesely, javed.absar, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D57511 llvm-svn: 353928
* [DebugInfo] Don't salvage load operations (PR40628).Jeremy Morse2019-02-121-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | Salvaging a redundant load instruction into a debug expression hides a memory read from optimisation passes. Passes that alter memory behaviour (such as LICM promoting memory to a register) aren't aware of these debug memory reads and leave them unaltered, making the debug variable location point somewhere unsafe. Teaching passes to know about these debug memory reads would be challenging and probably incomplete. Finding dbg.value instructions that need to be fixed would likely be computationally expensive too, as more analysis would be required. It's better to not generate debug-memory-reads instead, alas. Changed tests: * DeadStoreElim: test for salvaging of intermediate operations contributing to the dead store, instead of salvaging of the redundant load, * GVN: remove debuginfo behaviour checks completely, this behaviour is still covered by other tests, * InstCombine: don't test for salvaged loads, we're removing that behaviour. Differential Revision: https://reviews.llvm.org/D57962 llvm-svn: 353824
* [DebugInfo] Keep parameter DBG_VALUEs before prologue codeDavid Stenberg2019-02-122-1/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a preparatory change for removing the code from DebugHandlerBase::beginFunction() which changes the starting label for the first non-overlapping DBG_VALUEs of parameters to the beginning of the function. It does that to be able to show parameters when entering a function. However, that code does not consider what defines the values, which can result in the ranges for the debug values starting before their defining instructions. That code is removed in a follow-up patch. When prologue code is inserted, it leads to DBG_VALUEs that start directly in the entry block being moved down after the prologue instructions. This patch fixes that by stashing away DBG_VALUEs for parameters before emitting the prologue, and then reinserts them at the start of the block. This assumes that there is no target that somehow clobbers parameter registers in the frame setup; there is no such case in the lit tests at least. See PR40188 for more information. Reviewers: aprantl, dblaikie, rnk, jmorse Reviewed By: aprantl Subscribers: bjope, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D57510 llvm-svn: 353823
* Fix r353771 to target linux only (split-dwarf isn't supported on macho)David Blaikie2019-02-121-0/+2
| | | | llvm-svn: 353785
* DebugInfo: Split DWARF + gmlt + no-split-dwarf-inlining shouldn't emit ↵David Blaikie2019-02-121-0/+28
| | | | | | | | | | | | | | | anything to the .dwo file This configuration (due to r349207) was intended not to emit any DWO CU, but a degenerate CU was still being emitted - containing a header and a DW_TAG_compile_unit with no attributes. Under that situation, emit nothing to the .dwo file. (since this is a dynamic property of the input the .dwo file is still emitted, just with nothing in it (so a valid, but empty, ELF file) - if some other CU didn't satisfy this criteria, its DWO CU would still go there, etc) llvm-svn: 353771
* [SelectionDAGBuilder] Add restrictions to EmitFuncArgumentDbgValueBjorn Pettersson2019-02-112-0/+293
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes PR40587. When a dbg.value instrinsic is emitted to the DAG by using EmitFuncArgumentDbgValue the resulting DBG_VALUE is hoisted to the beginning of the entry block. I think the idea is to be able to locate a formal argument already from the start of the function. However, EmitFuncArgumentDbgValue only checked that the value that was used to describe a variable was originating from a function parameter, not that the variable itself actually was an argument to the function. So when for example assigning a local variable "local" the value from an argument "a", the assocated DBG_VALUE instruction would be hoisted to the beginning of the function, even if the scope for "local" started somewhere else (or if "local" was mapped to other values earlier in the function). This patch adds some logic to EmitFuncArgumentDbgValue to check that the variable being described actually is an argument to the function. And that the dbg.value being lowered already is in the entry block. Otherwise we bail out, and the dbg.value will be handled as an ordinary dbg.value (not as a "FuncArgumentDbgValue"). A tricky situation is when both the variable and the value is related to function arguments, but not neccessarily the same argument. We make sure that we do not describe the same argument more than once as a "FuncArgumentDbgValue". This solution works as long as opt has injected a "first" dbg.value that corresponds to the formal argument at the function entry. Reviewers: jmorse, aprantl Subscribers: jyknight, hiraditya, fedor.sergeev, dstenb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57702 llvm-svn: 353735
* [DebugInfo] Fix /usr/lib/debug llvm-symbolizer lookup with relative pathsJordan Rupprecht2019-02-111-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: rL189250 added a realpath call, and rL352916 because realpath breaks assumptions with some build systems. However, the /usr/lib/debug case has been clarified, falling back to /usr/lib/debug is currently broken if the obj passed in is a relative path. Adding a call to use absolute paths when falling back to /usr/lib/debug fixes that while still not making any realpath assumptions. This also adds a --fallback-debug-path command line flag for testing (since we probably can't write to /usr/lib/debug from buildbot environments), but was also verified manually: ``` $ rm -f path/to/dwarfdump-test.elf-x86-64 $ strace llvm-symbolizer --obj=relative/path/to/dwarfdump-test.elf-x86-64.debuglink 0x40113f |& grep dwarfdump ``` Lookups went to relative/path/to/dwarfdump-test.elf-x86-64, relative/path/to/.debug/dwarfdump-test.elf-x86-64, and then finally /usr/lib/debug/absolute/path/to/dwarfdump-test.elf-x86-64. Reviewers: dblaikie, samsonov Reviewed By: dblaikie Subscribers: krytarowski, aprantl, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57916 llvm-svn: 353730
* [mips][micromips] Fix how values in .gcc_except_table are calculatedPetar Jovanovic2019-02-071-6/+18
| | | | | | | | | | | | | | | | | When a landing pad is calculated in a program that is compiled for micromips with -fPIC flag, it will point to an even address. Such an error will cause a segmentation fault, as the instructions in micromips are aligned on odd addresses. This patch sets the last bit of the offset where a landing pad is, to 1, which will effectively be an odd address and point to the instruction exactly. r344591 fixed this issue for -static compilation. Patch by Aleksandar Beserminji. Differential Revision: https://reviews.llvm.org/D57677 llvm-svn: 353480
* [DebugInfo][llvm-symbolizer]Add some tests for edge cases when symbolizingJames Henderson2019-02-067-0/+300
| | | | | | | | | | | | This patch adds half a dozen new tests that test various edge cases in the behaviour of the symbolizer and DWARF data parsing. All of them test the current behaviour. Reviewed by: JDevlieghere, aprantl Differential Revision: https://reviews.llvm.org/D57741 llvm-svn: 353286
* [DEBUG_INFO][NVPTX] Generate DW_AT_address_class to get the values in debugger.Alexey Bataev2019-02-052-9/+267
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to https://docs.nvidia.com/cuda/archive/10.0/ptx-writers-guide-to-interoperability/index.html#cuda-specific-dwarf, the compiler should emit the DW_AT_address_class attribute for all variable and parameter. It means, that DW_AT_address_class attribute should be used in the non-standard way to support compatibility with the cuda-gdb debugger. Clang is able to generate the information about the variable address class. This information is emitted as the expression sequence `DW_OP_constu <DWARF Address Space> DW_OP_swap DW_OP_xderef`. The patch tries to find all such expressions and transform them into `DW_AT_address_class <DWARF Address Space>` if target is NVPTX and the debugger is gdb. If the expression is not found, then default values are used. For the local variables <DWARF Address Space> is set to ADDR_local_space(6), for the globals <DWARF Address Space> is set to ADDR_global_space(5). The values are taken from the table in the same section 5.2. CUDA-Specific DWARF Definitions. Reviewers: echristo, probinson Subscribers: jholewinski, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D57157 llvm-svn: 353203
* [DEBUGINFO] Reposting r352642: Handle restore instructions in LiveDebugValuesWolfgang Pieb2019-02-041-0/+189
| | | | | | | | | | | | | | | | | The LiveDebugValues pass recognizes spills but not restores, which can cause large gaps in location information for some variables, depending on control flow. This patch make LiveDebugValues recognize restores and generate appropriate DBG_VALUE instructions. This patch was posted previously with r352642 and reverted in r352666 due to buildbot errors. A missing return statement was the cause for the failures. Reviewers: aprantl, NicolaPrica Differential Revision: https://reviews.llvm.org/D57271 llvm-svn: 353089
* [DebugInfo] Fix mkdir use in testJordan Rupprecht2019-02-011-1/+1
| | | | llvm-svn: 352918
* [DebugInfo] Don't use realpath when looking up debug binary locations.Jordan Rupprecht2019-02-011-0/+17
| | | | | | | | | | | | | | | | | | | Summary: Using realpath makes assumptions about build systems that do not always hold true. The debug binary referred to from the .gnu_debuglink should exist in the same directory (or in a .debug directory, etc.), but the files may only exist as symlinks to a differently named files elsewhere, and using realpath causes that lookup to fail. This was added in r189250, and this is basically a revert + regression test case. Reviewers: dblaikie, samsonov, jhenderson Reviewed By: dblaikie Subscribers: llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D57609 llvm-svn: 352916
* [DWARF v5] Fix DWARF emitter and consumer to produce/expect a uleb for a ↵Wolfgang Pieb2019-02-011-4/+4
| | | | | | | | | | location description's length. Reviewer: davide, JDevliegere Differential Revision: https://reviews.llvm.org/D57550 llvm-svn: 352889
* [llvm-symbolizer][test] Rename and tweak tests using llvm-symbolizerJames Henderson2019-02-016-19/+22
| | | | | | | | | | | | | | | | | | | | Prior to this change, there are a few tests called llvm-symbolizer* in the DebugInfo test area. These really were testing either the DebugInfo or Symbolizer library, rather than the llvm-symbolizer tool itself, so this patch renames them to be clearer that they aren't explicitly tests for llvm-symbolizer (such tests belong in test/tools/llvm-symbolizer). This patch also reinstates the copying of a DWO file, removed previously in r352752. The test needs this so that it could possibly fail. Finally, some of the tests have been simplified slightly by removing unnecessary switches and/or unused check-prefixes. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D57518 llvm-svn: 352847
* [llvm-symbolizer][test] Extract tests from llvm-symbolizer.test and simplify ↵James Henderson2019-01-317-69/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | (#3) This is the fourth (and final for now) of a series of patches simplifying llvm-symbolizer tests. See r352752, r352753 and 352754 for the previous ones. This patch splits out several more distinct test cases from llvm-symbolizer.test into separate tests, and simplifies them in various ways including: 1) Building a test case for spaces in path from source, rather than using a pre-canned binary. This allows deleting of said binary and the source it was built from. 2) Switching to specifying addresses and objects directly on the command-line rather than via stdin. This also adds an explict test for the ability to specify a file and address as a line in stdin, since the majority of the tests have been migrated away from this approach, leaving this largely untested. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D57446 llvm-svn: 352756
* [llvm-symbolizer][test] Extract tests from llvm-symbolizer.test and simplify ↵James Henderson2019-01-315-73/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | (#2) This is the third of a series of patches simplifying llvm-symbolizer tests. See r352752 and r352753 for the previous two. This patch splits out a number of distinct test cases from llvm-symbolizer.test into separate tests, and simplifies them in various ways including: 1) using --obj/positional arguments for the input file and addresses instead of stdin, 2) using runtime-generated inputs rather than a pre-canned binary, and 3) testing more specifically (i.e. checking only what is interesting to the behaviour changed in the original commit for that test case). This patch also removes the test case for using --obj. The tools/llvm-symbolizer/basic.s test already tests this case. Finally, this patch adds a simple test case to the demangle switch test case to show that demangling happens by default. See https://bugs.llvm.org/show_bug.cgi?id=40070#c1 for the motivation. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D57446 llvm-svn: 352754
* [llvm-symbolizer][test] Extract tests from llvm-symbolizer.test and simplify ↵James Henderson2019-01-316-33/+31
| | | | | | | | | | | | | | | | | | (#1) This is the second of a series of patches simplifying llvm-symbolizer tests. See r352752 for the first. This one splits out 5 distinct test cases from llvm-symbolizer.test into separate tests, and simplifies them slightly by using --obj/positional arguments for the input file and addresses instead of stdin. See https://bugs.llvm.org/show_bug.cgi?id=40070#c1 for the motivation. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D57443 llvm-svn: 352753
* [llvm-symbolizer][test] Simplify test input readingJames Henderson2019-01-313-13/+4
| | | | | | | | | | | | | | | | | | This change migrates most llvm-symbolizer tests away from reading input via stdin and instead using --obj + positional arguments for the file and addresses respectively, which makes the tests easier to read. One exception is the test test/tools/llvm-symbolizer/pdb/pdb.test, which was doing some manipulation on the input addresses. This patch simplifies this somewhat, but it still reads from stdin. More changes to follow to simplify/break-up other tests. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D57441 llvm-svn: 352752
* Reverting r352642 - Handle restore instructions in LiveDebugValues - as it's ↵Wolfgang Pieb2019-01-301-189/+0
| | | | | | | | causing assertions on some buildbots. llvm-svn: 352666
* The test comitted with r348896 needed -march=x86=64 on the llc command line.Wolfgang Pieb2019-01-301-1/+1
| | | | llvm-svn: 352651
* [DEBUGINFO] Handle restore instructions in LiveDebugValuesWolfgang Pieb2019-01-301-0/+189
| | | | | | | | | | | | | The LiveDebugValues pass recognizes spills but not restores, which can cause large gaps in location information for some variables, depending on control flow. This patch make LiveDebugValues recognize restores and generate appropriate DBG_VALUE instructions. Reviewers: aprantl, NicolaPrica Differential Revision: https://reviews.llvm.org/D57271 llvm-svn: 352642
* Remove 'XFAIL: powerpc64' from a debuginfo testJeremy Morse2019-01-291-4/+0
| | | | | | | | | | | | This test started XPASSing with r352467, and the change in behaviour performed by that patch does appear to fix the cause of the original XFAIL (missing FrameIndex DBG_VALUE), which I've replicated locally with -mtriple=powerpc64--. I'll write this up in PR21881 which documents the XFAIL, and seek confirmation I haven't overlooked something here. llvm-svn: 352471
* [DebugInfo][DAG] Process FrameIndex dbg.values unconditionallyJeremy Morse2019-01-292-1/+80
| | | | | | | | | | | | | | | A FrameIndex should be valid throughout a block regardless of what instructions get selected in that block -- therefore we shouldn't harness dbg.values that refer to FrameIndexes to an SDNode. There are numerous codegen reasons why an SDNode never appears or doesn't become a location that a DBG_VALUE can refer to. None of them actually affect the variable location. Therefore, before any other tests to encode dbg_values in a SelectionDAG, identify FrameIndex operands and encode them unattached to any SDNode. Differential Revision: https://reviews.llvm.org/D57328 llvm-svn: 352467
* Fix an incorrectly configured test.Jeremy Morse2019-01-291-0/+2
| | | | | | This should have had a target triple in it, my mistake. llvm-svn: 352460
* [DebugInfo][DAG] Avoid re-ordering of DBG_VALUEsJeremy Morse2019-01-283-9/+57
| | | | | | | | | | | | | | | | This patch improves the placement of DBG_VALUEs when by SelectionDAG, which as documented in PR40427 can go very wrong. At the core of this is ProcessSourceNode, which assumes the last instruction in a BB is the start of the last processed IR instruction, which isn't always true. Instead, use a helper function to call InstrEmitter::EmitNode, that records before-and-after iterators and determines the first of any new instruction created during emission. This is passed to ProcessSourceNode, which can then make more elightened decisions about ordering for DBG_VALUE placement. Differential revision: https://reviews.llvm.org/D57163 llvm-svn: 352350
* [MBP] Don't move bottom block before header if it can't reduce taken branchesGuozhi Wei2019-01-251-9/+8
| | | | | | | | | | | | | | | | | | If bottom of block BB has only one successor OldTop, in most cases it is profitable to move it before OldTop, except the following case: -->OldTop<- | . | | . | | . | ---Pred | | | BB----- Move BB before OldTop can't reduce the number of taken branches, this patch detects this case and prevent the moving. Differential Revision: https://reviews.llvm.org/D57067 llvm-svn: 352236
* Reapply: [mips] Handle MipsMCExpr sub-expression for the MEK_DTPREL tagSimon Atanasyan2019-01-241-2/+24
| | | | | | | | | | | | | | | | | | | | | This reapplies commit r351987 with a failed test fix. Now the test accepts both DW_OP_GNU_push_tls_address and DW_OP_form_tls_address opcode. Original commit message: ``` This is a fix for a regression introduced by the rL348194 commit. In that change new type (MEK_DTPREL) of MipsMCExpr expression was added, but in some places of the code this type of expression considered as unexpected. This change fixes the bug. The MEK_DTPREL type of expression is used for marking TLS DIEExpr only and contains a regular sub-expression. Where we need to handle the expression, we retrieve the sub-expression and handle it in a common way. ``` llvm-svn: 352034
* DebugInfo: Use assembly label arithmetic for address pool size for easier ↵David Blaikie2019-01-241-6/+8
| | | | | | | | | reading/editing Recommits 350048, 350050 That broke buildbots because of some typos in the test case. llvm-svn: 352019
* llvm-symbolizer: Extract individual test cases now that it's easier to use ↵David Blaikie2019-01-2418-159/+0
| | | | | | | | | | directly (without a piped input file) Pulling out the split-dwarf tests by way of example of how I think llvm-symbolizer should be tested going forward. Open to debate/discussion, though. llvm-svn: 352004
* Revert "[mips] Handle MipsMCExpr sub-expression for the MEK_DTPREL tag"Amara Emerson2019-01-241-24/+2
| | | | | | This reverts commit r351987 as it broke some bots. llvm-svn: 351998
* [mips] Handle MipsMCExpr sub-expression for the MEK_DTPREL tagSimon Atanasyan2019-01-231-2/+24
| | | | | | | | | | | | | | This is a fix for a regression introduced by the rL348194 commit. In that change new type (MEK_DTPREL) of MipsMCExpr expression was added, but in some places of the code this type of expression considered as unexpected. This change fixes the bug. The MEK_DTPREL type of expression is used for marking TLS DIEExpr only and contains a regular sub-expression. Where we need to handle the expression, we retrieve the sub-expression and handle it in a common way. llvm-svn: 351987
* [DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target.Alexey Bataev2019-01-236-5249/+5267
| | | | | | | | Enable full support for the debug info. Differential revision: https://reviews.llvm.org/D46189 llvm-svn: 351974
* Revert "[DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target."Alexey Bataev2019-01-236-5267/+5249
| | | | | | | This reverts commit r351972. Some pieces of the patch was not applied correctly. llvm-svn: 351973
* [DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target.Alexey Bataev2019-01-236-5249/+5267
| | | | | | | | | Enable full support for the debug info. Recommit to fix the emission of the not required closing brace. Differential revision: https://reviews.llvm.org/D46189 llvm-svn: 351972
* [llvm-symbolizer] Improve compatibility of --functions with GNU addr2lineJames Henderson2019-01-231-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | This fixes https://bugs.llvm.org/show_bug.cgi?id=40072. GNU addr2line's --functions switch is off by default, has a short alias of -f, and does not take an argument. This patch changes llvm-symbolizer to allow the second and third point (changing the default behaviour may have negative impacts on users). If the option is missing a value, it now treats it as "linkage". This change does cause one previously valid command-line to behave differently. Before --functions <value> was accepted, but now only --functions=<value> is allowed (as well as --functions). The old behaviour will result in the value being treated as a positional argument. The previous testing for --functions=short has been pulled out into a new test that also tests the other accepted values and option formats. Reviewed by: ruiu Differential Revision: https://reviews.llvm.org/D57049 llvm-svn: 351968
* Revert "[DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target."Haojian Wu2019-01-235-5249/+5249
| | | | | | | | | | | | | | | | | | | | | | This reverts commit r351846. This patch may generate illegal assembly code, see ``` $ ./bin/clang -cc1 -triple nvptx64-nvidia-cuda -aux-triple x86_64-grtev4-linux-gnu -S -disable-free -disable-llvm-verifier -discard-value-names -main-file-name new.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -fmerge-all-constants -mdisable-fp-elim -relaxed-aliasing -no-integrated-as -mpie-copy-relocations -munwind-tables -fcuda-is-device -target-feature +ptx60 -target-cpu sm_35 -dwarf-column-info -debug-info-kind=line-directives-only -dwarf-version=2 -debugger-tuning=gdb -o empty.s -x cuda empty.cc $ cat empty.s // // Generated by LLVM NVPTX Back-End // .version 6.0 .target sm_35 .address_size 64 } ``` llvm-svn: 351966
* [CodeView] Allow empty types in member functionsJosh Stone2019-01-231-0/+72
| | | | | | | | | | | | | | | | | | | | | Summary: `CodeViewDebug::lowerTypeMemberFunction` used to default to a `Void` return type if the function's type array was empty. After D54667, it started blindly indexing the 0th item for the return type, which fails in `getOperand` for empty arrays if assertions are enabled. This patch restores the `Void` return type for empty type arrays, and adds a test generated by Rust in line-only debuginfo mode. Reviewers: zturner, rnk Reviewed By: rnk Subscribers: hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D57070 llvm-svn: 351910
* [DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target.Alexey Bataev2019-01-225-5249/+5249
| | | | | | | | | | | | Summary: Enable full support for the debug info. Reviewers: echristo Subscribers: jholewinski, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D46189 llvm-svn: 351846
* [DEBUG_INFO, NVPTX] Fix relocation info.Alexey Bataev2019-01-222-2/+6
| | | | | | | | | | | | Summary: Initial function labels must follow the debug location for the correct relocation info generation. Reviewers: tra, jlebar, echristo Subscribers: jholewinski, llvm-commits Differential Revision: https://reviews.llvm.org/D45784 llvm-svn: 351843
* [llvm-symbolizer] Add -no-demangle as alias for -demangle=falseDmitry Venikov2019-01-211-0/+13
| | | | | | | | | | | | | | Summary: Provides -no-demangle as alias for -demangle=false. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40075 Reviewers: jhenderson, ruiu Reviewed By: jhenderson Subscribers: erik.pilkington, rupprecht, llvm-commits Differential Revision: https://reviews.llvm.org/D56773 llvm-svn: 351735
* [Test] Fix debug-loc-0.mir with EXPENSIVE_CHECKSJonas Devlieghere2019-01-171-1/+1
| | | | | | The `llc` invocation was missing `-start-before=machine-cp`. llvm-svn: 351464
* [AsmPrinter] Collapse .loc 0 0 directivesJonas Devlieghere2019-01-161-0/+104
| | | | | | | | | | | | | | | | Currently we do not always collapse subsequent .loc 0 0 directives. The reason is that we were checking for a PrevInstLoc which is not set when we emit a line-0 record. We should only check the LastAsmLine, which seems to be created exactly for this purpose. // When we emit a line-0 record, we don't update PrevInstLoc; so look at // the last line number actually emitted, to see if it was line 0. unsigned LastAsmLine = Asm->OutStreamer->getContext().getCurrentDwarfLoc().getLine(); Differential revision: https://reviews.llvm.org/D56767 llvm-svn: 351395
OpenPOWER on IntegriCloud