summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[DEBUGINFO] Add flag for DWARF2 or less to use sections as references."Alexey Bataev2018-03-011-15/+8
| | | | | | | This reverts commit r326328 to remove checks for emission of certain sections after discussion with Eric Christofer. llvm-svn: 326436
* [TLS] use emulated TLS if the target supports only this modeChih-Hung Hsieh2018-02-281-1/+1
| | | | | | | | | | | | | | | Emulated TLS is enabled by llc flag -emulated-tls, which is passed by clang driver. When llc is called explicitly or from other drivers like LTO, missing -emulated-tls flag would generate wrong TLS code for targets that supports only this mode. Now use useEmulatedTLS() instead of Options.EmulatedTLS to decide whether emulated TLS code should be generated. Unit tests are modified to run with and without the -emulated-tls flag. Differential Revision: https://reviews.llvm.org/D42999 llvm-svn: 326341
* [DEBUGINFO] Add flag for DWARF2 or less to use sections as references.Alexey Bataev2018-02-281-8/+15
| | | | | | | | | | | | | | | | | Summary: Some targets does not support labels inside debug sections, but support references in form `section +|- offset`. Patch adds initial support for this. Also, this patch disables emission of all additional debug sections that may have labels inside of it (like pub sections and string tables). Reviewers: probinson, echristo Subscribers: JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D43627 llvm-svn: 326328
* [DebugInfo] Support DWARF v5 source code embedding extensionScott Linder2018-02-231-2/+3
| | | | | | | | | | | | | | | | | | | In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. In this extension a content type is added, DW_LNCT_LLVM_source, which contains the embedded source code of the file. Add new optional attribute for !DIFile IR metadata called source which contains source text. Use this to output the source to the DWARF line table of code objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM to support optional source. Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output format of llvm-dwarfdump to make room for the new attribute on file_names entries, and support embedded sources for the -source option in llvm-objdump. Differential Revision: https://reviews.llvm.org/D42765 llvm-svn: 325970
* Use a stable topological sort in DwarfCompileUnit::createScopeChildrenDIE()Adrian Prantl2018-02-081-13/+67
| | | | | | | | | | | | This addresses review feedback for D42940. The topological sort is slightly more expensive but it can now also detect cycles in the dependencies and actually works correctly. rdar://problem/37217988 Differential Review: https://reviews.llvm.org/D43036 llvm-svn: 324677
* Fix a crash when emitting DIEs for variable-length arraysAdrian Prantl2018-02-061-1/+29
| | | | | | | | | | | | | VLAs may refer to a previous DIE to express the DW_AT_count of their type. Clang generates an artificial "vla_expr" variable for this. If this DIE hasn't been created yet LLVM asserts. This patch fixes this by sorting the local variables so that dependencies come before they are needed. It also replaces the linear scan in DWARFFile with a std::map, which can be faster. Differential Revision: https://reviews.llvm.org/D42940 llvm-svn: 324412
* [DebugInfo] Fix fragment offset emission order for symbol locationsMikael Holmen2018-01-291-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When emitting the location for a global variable with fragmented debug expressions, make sure that the offset pieces, which represent optimized-out parts of the variable, are emitted before their succeeding fragments' expressions. Previously, if the succeeding fragment's location was a symbol, the offset piece was emitted after, rather than before, that symbol's expression. This effectively meant that the symbols were associated with the wrong parts of the variable. This fixes PR36085. Patch by: David Stenberg Reviewers: aprantl, probinson, dblaikie Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D42527 llvm-svn: 323644
* [DebugInfo] Emit DWARF reference for DIVariable 'count' in DISubrangeSander de Smalen2018-01-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the codegen of DWARF debug info for non-constant 'count' fields for DISubrange. This is patch [2/3] in a series to extend LLVM's DISubrange Metadata node to support debugging of C99 variable length arrays and vectors with runtime length like the Scalable Vector Extension for AArch64. It is also a first step towards representing more complex cases like arrays in Fortran. Reviewers: echristo, pcc, aprantl, dexonsmith, clayborg, kristof.beyls, dblaikie Reviewed By: aprantl Subscribers: fhahn, aemerson, rengolin, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D41696 llvm-svn: 323323
* [DWARFv5] CodeGen support for MD5 file checksumsPaul Robinson2018-01-121-9/+7
| | | | | | | | | | Pass MD5 checksums through from IR to assembly/object files. After this, getting Clang to compute the MD5 should be the last step to supporting MD5 in the DWARF v5 line table header. Differential Revision: https://reviews.llvm.org/D41926 llvm-svn: 322391
* [DWARFv5] MC support for MD5 file checksumsPaul Robinson2018-01-091-3/+4
| | | | | | | Extend .file directive syntax to allow specifying an MD5 checksum for the source file. Emit the checksums in DWARF v5 line tables. llvm-svn: 322134
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-5/+5
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* [DebugInfo] Fix potential CU mismatch for SubprogramScopeDIEs.Jonas Devlieghere2017-11-151-7/+13
| | | | | | | | | | | | | | | | | In constructAbstractSubprogramScopeDIE there can be a potential mismatch between `this` and the CU of ContextDIE when a scope is shared between two DISubprograms belonging to a different CU. In that case, `this` is the CU that was specified in the IR, but the CU of ContextDIE is that of the first subprogram that was emitted. This patch fixes the mismatch by looking up the CU of ContextDIE, and switching to use that. This fixes PR35212 (https://bugs.llvm.org/show_bug.cgi?id=35212) Patch by Philip Craig! Differential revision: https://reviews.llvm.org/D39981 llvm-svn: 318289
* Move TargetFrameLowering.h to CodeGen where it's implementedDavid Blaikie2017-11-031-1/+1
| | | | | | | | | | | This header already includes a CodeGen header and is implemented in lib/CodeGen, so move the header there to match. This fixes a link error with modular codegeneration builds - where a header and its implementation are circularly dependent and so need to be in the same library, not split between two like this. llvm-svn: 317379
* Deprecate DwarfUnit::addBlockByrefAddress().Adrian Prantl2017-10-121-0/+6
| | | | | | | | | | | | The clang frontend already creates a DIExpression that replicates the logic in addBlockByrefAddress() exactly, thus making this function effectively unreachable. To guard against human error I'm hereby marking the function with an assertion and let it hit the bots before eventually removing it. rdar://problem/31629055 llvm-svn: 315636
* Remove -generate-dwarf-pub-sections flag.Peter Collingbourne2017-09-121-14/+1
| | | | | | | | | This flag is unnecessary for testing because we can get the coverage we need by adjusting CU attributes. Differential Revision: https://reviews.llvm.org/D37725 llvm-svn: 313079
* IR: Represent -ggnu-pubnames with a flag on the DICompileUnit.Peter Collingbourne2017-09-121-4/+26
| | | | | | | | This allows the flag to be persisted through to LTO. Differential Revision: https://reviews.llvm.org/D37655 llvm-svn: 313078
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-08-171-12/+30
| | | | | | other minor fixes (NFC). llvm-svn: 311124
* Assert that the offset of a DBG_VALUE is always 0. (NFC)Adrian Prantl2017-08-021-2/+4
| | | | llvm-svn: 309834
* Remove the unused Offset field from MachineLocation (NFC)Adrian Prantl2017-08-021-6/+2
| | | | | | rdar://problem/33580047 llvm-svn: 309831
* Remove unused includes of MachineLocation.h (NFC)Adrian Prantl2017-08-021-0/+1
| | | | llvm-svn: 309824
* Remove unreachable code. (NFC)Adrian Prantl2017-08-021-13/+2
| | | | | | | | MachineLocation::getOffset() always returns 0. rdar://problem/33580047 llvm-svn: 309823
* DebugInfo: Ensure imported entities at the top level of an inlined function ↵David Blaikie2017-07-271-16/+15
| | | | | | | | | | | | | | | | | | | | | | don't cause degenerate concrete definitions Local imported entities at the top level of a subprogram were being handled differently from those in nested scopes - that different handling would cause pseudo concrete out-of-line definitions to be created (but without any of their attributes, nor an abstract_origin) in the case where there was no real concrete definition. These local imported entities also only appeared in the concrete definition where those imported entities in nested scopes appear in all cases (abstract, concrete, and inlined). This change at least makes top level case handle the same as the others - though there's a FIXME to improve this to /only/ emit them into the abstract origin (though this requires more plumbing - like the abstract subprogram and variable handling that must defer population until the end of the unit to discover if there is an abstract origin, or only a standalone concrete definition). llvm-svn: 309237
* Debug Info: Add a file: field to DIImportedEntity.Adrian Prantl2017-07-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | DIImportedEntity has a line number, but not a file field. To determine the decl_line/decl_file we combine the line number from the DIImportedEntity with the file from the DIImportedEntity's scope. This does not work correctly when the parent scope is a DINamespace or a DIModule, both of which do not have a source file. This patch adds a file field to DIImportedEntity to unambiguously identify the source location of the using/import declaration. Most testcase updates are mechanical, the interesting one is the removal of the FIXME in test/DebugInfo/Generic/namespace.ll. This fixes PR33822. See https://bugs.llvm.org/show_bug.cgi?id=33822 for more context. <rdar://problem/33357889> https://bugs.llvm.org/show_bug.cgi?id=33822 Differential Revision: https://reviews.llvm.org/D35583 llvm-svn: 308398
* [DWARF] Move a couple of member functions to the DWARFUnit baseclass. NFC.Wolfgang Pieb2017-06-301-20/+0
| | | | | | | | Reviewer: dblaikie Differential revision: https://reviews.llvm.org/D34765 llvm-svn: 306771
* Align definition of DW_OP_plus with DWARF spec [3/3]Florian Hahn2017-06-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things. The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack. This is done in three stages: • The first patch (LLVM) adds support for DW_OP_plus_uconst. • The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst. • The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions. Patch by Sander de Smalen. Reviewers: echristo, pcc, aprantl Reviewed By: aprantl Subscribers: fhahn, javed.absar, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D33894 llvm-svn: 305386
* DebugInfo: Produce debug_{gnu_}pub{names,types} entries when explicitly ↵David Blaikie2017-05-251-4/+4
| | | | | | | | | | | | | | | | | requested, even in -gmlt or when empty Turns out gold doesn't use the DW_AT_GNU_pubnames to decide whether to parse the rest of the DIEs when building gdb-index. This causes gold to trip over LLVM's output when there are DW_FORM_ref_addr present. Gold does use the presence of a debug_gnu_pub{names,types} entry for the CU to skip parsing the debug_info portion, so make sure that's included even when empty (technically, when empty there couldn't be any ref_addr anyway - it only came up when gmlt didn't produce any (even non-empty) pubnames - but given what that reveals about gold's implementation, this seems like a good thing to do for consistency). llvm-svn: 303894
* DWARF: Avoid cross-CU references under FissionDavid Blaikie2017-05-121-3/+39
| | | | | | | | | | | | | | | | | | Turns out that the Fission/Split DWARF package format (DWP) is currently insufficient to handle cross-CU (ref_addr) references. So for now, duplicate any debug info needed in these situations: * inlined_subroutine's abstract_origin * inlined variable's abstract_origin * types Keep the ref_addr behavior in general, including in the split DWARF inline debug info that can be emitted into the object files for online symbolication. Keep a flag to use the old (ref_addr) behavior for testing ways of addressing this limitation in the DWP tool (& for those not using DWP packaging). llvm-svn: 302858
* Fix bug that caused DwarfExpression to drop DW_OP_deref from FI locationsAdrian Prantl2017-04-191-5/+9
| | | | | | | | | | | - introduced in r300522 and found via the Swift LLDB testsuite. The fix is to set the location kind to memory whenever an FrameIndex location is emitted. rdar://problem/31707602 llvm-svn: 300793
* Revert "Fix bug that caused DwarfExpression to drop DW_OP_deref from FI ↵Adrian Prantl2017-04-191-9/+5
| | | | | | | | locations" This reverts commit r300790. llvm-svn: 300792
* Fix bug that caused DwarfExpression to drop DW_OP_deref from FI locationsAdrian Prantl2017-04-191-5/+9
| | | | | | | | | | | - introduced in r300522 and found via the Swift LLDB testsuite. The fix is to set the location kind to memory whenever an FrameIndex location is emitted. rdar://problem/31707602 llvm-svn: 300790
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-181-13/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* Refactor code to reduce indentation and improve readability. (NFC)Adrian Prantl2017-03-231-43/+53
| | | | llvm-svn: 298665
* Fix a bug when emitting debug info for partially constant global variables.Adrian Prantl2017-03-231-7/+2
| | | | | | | While fixing a malformed testcase, I discovered that the code exercised by it was wrong, too. llvm-svn: 298664
* Replace uses of DwarfExpression::addMachineReg* with addMachineRegExpressionAdrian Prantl2017-03-201-28/+35
| | | | | | | | | | | | | and mark the methods as protected. Besides reducing the surface area of DwarfExpression, this is in preparation for an upcoming bugfix in the DwarfExpression implementation, for which it will be necessary to defer emitting register operations until the rest of the expression is known. NFC llvm-svn: 298309
* Rename methods in DwarfExpression to adhere to the LLVM coding guidelines.Adrian Prantl2017-03-161-10/+10
| | | | | | NFC. llvm-svn: 297966
* Add missing module/license header. NFC.Paul Robinson2017-03-011-0/+13
| | | | llvm-svn: 296550
* [DWARFv5] Emit new unit header format.Paul Robinson2017-02-281-1/+4
| | | | | | | | | Requesting DWARF v5 will now get you the new compile-unit and type-unit headers. llvm-dwarfdump will also recognize them. Differential Revision: http://reviews.llvm.org/D30206 llvm-svn: 296514
* Debug Info: Sort frame index expressions before emitting them.Adrian Prantl2017-02-171-8/+5
| | | | | | | | | | This fixes PR31381, which caused an assertion and/or invalid debug info. This affects debug variables that have multiple fragments in the MMI side (i.e.: in the stack frame) table. rdar://problem/30571676 llvm-svn: 295486
* DebugInfo: ensure type and namespace names are included in pubnames/pubtypes ↵David Blaikie2017-02-031-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | even when they are only present in type units While looking to add support for placing singular types (types that will only be emitted in one place (such as attached to a strong vtable or explicit template instantiation definition)) not in type units (since type units have overhead) I stumbled across that change causing an increase in pubtypes. Turns out we were missing some types from type units if they were only referenced from other type units and not from the debug_info section. This fixes that, following GCC's line of describing the offset of such entities as the CU die (since there's no compile unit-relative offset that would describe such an entity - they aren't in the CU). Also like GCC, this change prefers to describe the type stub within the CU rather than the "just use the CU offset" fallback where possible. This may give the DWARF consumer some opportunity to find the extra info in the type stub - though I'm not sure GDB does anything with this currently. The size of the pubnames/pubtypes sections now match exactly with or without type units enabled. This nearly triples (+189%) the pubtypes section for a clang self-host and grows pubnames by 0.07% (without compression). For a total of 8% increase in debug info sections of the objects of a Split DWARF build when using type units. llvm-svn: 293971
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-201-64/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-66/+64
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-64/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-66/+64
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-64/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* DebugInfo: Address non-deterministic output (iterating a SmallPtrSet) in 289697David Blaikie2016-12-151-2/+0
| | | | | | | | Post-commit review feedback from Adrian Prantl. Hopefully this fixes that up :) llvm-svn: 289892
* DebugInfo: Emit ranges for functions with DISubprograms but lacking ↵David Blaikie2016-12-151-17/+12
| | | | | | | | | locations on any instructions This seems more consistent, and helps tidy up/simplify some other code in this change. llvm-svn: 289889
* Fix LLVM's use of DW_OP_bit_piece in DWARF expressions.Adrian Prantl2016-12-091-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM's use of DW_OP_bit_piece is incorrect and a based on a misunderstanding of the wording in the DWARF specification. The offset argument of DW_OP_bit_piece refers to the offset into the location that is on the top of the DWARF expression stack, and not an offset into the source variable. This has since also been clarified in the DWARF specification. This patch fixes all uses of DW_OP_bit_piece to emit the correct offset and simplifies the DwarfExpression class to semi-automaticaly emit empty DW_OP_pieces to adjust the offset of the source variable, thus simplifying the code using DwarfExpression. While this is an incompatible bugfix, in practice I don't expect this to be much of a problem since LLVM's old interpretation and the correct interpretation of DW_OP_bit_piece differ only when there are gaps in the fragmented locations of the described variables or if individual fragments are smaller than a byte. LLDB at least won't interpret locations with gaps in them because is has no way to present undefined bits in a variable, and there is a high probability that an old-form expression will be malformed when interpreted correctly, because the DW_OP_bit_piece offset will be outside of the location at the top of the stack. As a nice side-effect, this patch enables us to use a more efficient encoding for subregisters: In order to express a sub-register at a non-zero offset we now use a DW_OP_bit_piece instead of shifting the value into place manually. This patch also adds missing test coverage for code paths that weren't exercised before. <rdar://problem/29335809> Differential Revision: https://reviews.llvm.org/D27550 llvm-svn: 289266
* [DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operationAdrian Prantl2016-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | so we can stop using DW_OP_bit_piece with the wrong semantics. The entire back story can be found here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's offset field to mean the offset into the source variable rather than the offset into the location at the top the DWARF expression stack. In order to be able to fix this in a subsequent patch, this patch introduces a dedicated DW_OP_LLVM_fragment operation with the semantics that we used to apply to DW_OP_bit_piece, which is what we actually need while inside of LLVM. This patch is complete with a bitcode upgrade for expressions using the old format. It does not yet fix the DWARF backend to use DW_OP_bit_piece correctly. Implementation note: We discussed several options for implementing this, including reserving a dedicated field in DIExpression for the fragment size and offset, but using an custom operator at the end of the expression works just fine and is more efficient because we then only pay for it when we need it. Differential Revision: https://reviews.llvm.org/D27361 rdar://problem/29335809 llvm-svn: 288683
* This change removes the dependency on DwarfDebug that was used for ↵Greg Clayton2016-12-011-1/+1
| | | | | | | | | | | | | DW_FORM_ref_addr by making a new DIEUnit class in DIE.cpp. The DIEUnit class represents a compile or type unit and it owns the unit DIE as an instance variable. This allows anyone with a DIE, to get the unit DIE, and then get back to its DIEUnit without adding any new ivars to the DIE class. Why was this needed? The DIE class has an Offset that is always the CU relative DIE offset, not the "offset in debug info section" as was commented in the header file (the comment has been corrected). This is great for performance because most DIE references are compile unit relative and this means most code that accessed the DIE's offset didn't need to make it into a compile unit relative offset because it already was. When we needed to emit a DW_FORM_ref_addr though, we needed to find the absolute offset of the DIE by finding the DIE's compile/type unit. This class did have the absolute debug info/type offset and could be added to the CU relative offset to compute the absolute offset. With this change we can easily get back to a DIE's DIEUnit which will have this needed offset. Prior to this is required having a DwarfDebug and required calling: DwarfCompileUnit *DwarfDebug::lookupUnit(const DIE *CU) const; Now we can use the DIEUnit class to do so without needing DwarfDebug. All clients now use DIEUnit objects (the DwarfDebug stack and the DwarfLinker). A follow on patch for the DWARF generator will also take advantage of this. Differential Revision: https://reviews.llvm.org/D27170 llvm-svn: 288399
* Emit the DW_AT_type for a C++ static member definitionAdrian Prantl2016-11-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | if it is more specific than the one in its DW_AT_specification. If a static member is an array, the translation unit containing the member definition may have a more specific type (including its length) than TUs only seeing the class declaration. This patch adds a DW_AT_type to the member's DW_TAG_variable in addition to the DW_AT_specification in these cases. The member type in the DW_AT_specification still shows the more generic type (without the length) to avoid defeating type uniquing. The DWARF standard discourages “duplicating” a DW_AT_type in a member variable definition but doesn’t explicitly forbid it. Having the more specific type (with the array length) available is what allows the debugger to print the contents of a static array member variable. https://reviews.llvm.org/D26368 rdar://problem/28706946 llvm-svn: 286302
OpenPOWER on IntegriCloud