summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/X86
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field"Jeremy Morse2020-02-129-51/+25
| | | | | | | | | | | | | | | | | | | | | | | 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-291-211/+0
| | | | | | | | | | | | | | | ... 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-241-2/+2
| | | | | | | | instead of -start-after=patchable-function To break order dependency between livedebugvalues and patchable-function. (cherry picked from commit 26ba1f77b55e7a961acc05d94bfa4b677a9e5d83)
* 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.
* [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
* 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-2412-18/+18
| | | | "frame-pointer"="none" as cleanups after D56351
* Migrate function attribute "no-frame-pointer-elim-non-leaf" to ↵Fangrui Song2019-12-242-2/+2
| | | | "frame-pointer"="non-leaf" as cleanups after D56351
* Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" ↵Fangrui Song2019-12-2440-54/+54
| | | | 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-201-12/+0
| | | | | | | | 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-201-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. 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
* 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
* [OPT-DBG] Teach DbgEntityHistoryCalculator about meta-instructions.Tom Weaver2019-12-203-2/+158
| | | | | | | | | | | | | | 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-181-2/+2
| | | | | | | | 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-181-2/+2
| | | | | | Reverted due to build failure on windows bots. This reverts commit bb1b0bc4e57428ce364d3d6c075ff03cb8973462.
* [DebugInfo] Correctly handle salvaged casts and split fragments at ISelstozer2019-12-181-2/+2
| | | | | | | | | | | | | | | 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
* [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
|
* [DebugInfo] Nerf placeDbgValues, with prejudiceJeremy Morse2019-12-093-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Attempt to fix a debuginfo test that wasn't as generic as I thoughtJeremy Morse2019-12-061-0/+70
| | | | | | | | | 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.
* [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
* [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
* [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
* 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@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
* [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
* 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-186-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-185-14/+14
| | | | This reverts commit c0f6ad7d1f3ccb9d0b9ce9ef8dfa06409ccf1b3e to fix the buildbots.
* DWARF location lists: Add section index dumpingPavel Labath2019-11-185-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1510-25/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud