summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Simplify control flow in the the DWARF expression compilerAdrian Prantl2016-11-021-14/+15
| | | | | | by refactoring common code into a DwarfExpressionCursor wrapper. llvm-svn: 285827
* DebugInfo: support for DWARFv5 DW_AT_alignment attributeVictor Leschuk2016-10-261-1/+11
| | | | | | | | | | | | * Assume that clang passes non-zero alignment value to DIBuilder only in case when it was forced by C++11 'alignas', C11 '_Alignas' or compiler attribute '__attribute__((aligned (N)))'. * Emit DW_AT_alignment if alignment is specified for type/object. Differential Revision: https://reviews.llvm.org/D24425 llvm-svn: 285189
* Revert r285181 "DebugInfo: support for DWARFv5 DW_AT_alignment attribute".Vassil Vassilev2016-10-261-11/+1
| | | | | | The commit broke the builds. llvm-svn: 285183
* DebugInfo: support for DWARFv5 DW_AT_alignment attributeVictor Leschuk2016-10-261-1/+11
| | | | | | | | | | | | * Assume that clang passes non-zero alignment value to DIBuilder only in case when it was forced by C++11 'alignas', C11 '_Alignas' or compiler attribute '__attribute__((aligned (N)))'. * Emit DW_AT_alignment if alignment is specified for type/object. Differential Revision: https://reviews.llvm.org/D24425 llvm-svn: 285181
* Invoke add-discriminator at -g0 -fsample-profileDehao Chen2016-10-071-1/+1
| | | | | | | | | | | | Summary: -fsample-profile needs discriminator, which will not be added if built with -g0. This patch makes sure the discriminator is added for sample-profile at -g0. A followup patch will be send out to update clang tests. Reviewers: davidxl, dblaikie, echristo, dnovillo Subscribers: mehdi_amini, probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D25132 llvm-svn: 283565
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-131-55/+24
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* [COFF, Dwarf] Don't emit DW_AT_location for dllimported entitiesDavid Majnemer2016-07-091-47/+54
| | | | | | | There exists no relocation which can describe the address of a dllimported variable: do not try to describe their location. llvm-svn: 274986
* DWARF: Omit DW_AT_APPLE attributes (except ObjC ones) when not targeting LLDBDavid Blaikie2016-05-241-1/+2
| | | | | | | | | | | | | | | These attributes aren't used by other debuggers (& may be confused with other DWARF extensions) so they just waste space (about 1.5% on .dwo file size on a random large program I tested). We could remove the ObjC property ones too, but I figured they were probably more necessary when trying to understand ObjC (I could be wrong though) & so any debugger interested in working with ObjC would use them, perhaps? (also, there are some legacy tests in Clang that test for them - making it one of those annoying cross-project commits and/or cleanup to refactor those tests) llvm-svn: 270613
* CodeGen: Do not require a MachineFunction just to create a DIEDwarfExpression.Peter Collingbourne2016-05-201-3/+5
| | | | | | | | | We are about to start using DIEDwarfExpression to create global variable DIEs, which happens before we generate code for functions. Differential Revision: http://reviews.llvm.org/D20412 llvm-svn: 270257
* Reverting 268054 & 268063 as they caused PR27579.Amjad Aboud2016-04-301-108/+31
| | | | llvm-svn: 268150
* Recommitted r264280 "Supporting all entities declared in lexical scope in ↵Amjad Aboud2016-04-291-31/+108
| | | | | | | | LLVM debug info." After fixing PR26942 in r267004. llvm-svn: 268054
* [DWARF] Force a linkage_name on an inlined subprogram's abstract origin.Paul Robinson2016-04-181-1/+2
| | | | | | | | | | | | | When we suppress linkage names, for a non-inlined subprogram the name can still be found in the object-file symbol table, because we have the code address of the subprogram. This is not necessarily the case for an inlined subprogram, so we still want to emit the linkage name in the DWARF. Put this on the abstract-origin DIE because it's common to all inlined instances. Differential Revision: http://reviews.llvm.org/D18706 llvm-svn: 266692
* Drop debug info for DISubprograms that are not referenced by anythingAdrian Prantl2016-04-091-19/+0
| | | | | | | | | | | | | | | | | | | | | This patch drops the debug info for all DISubprograms that are (a) not attached to an llvm::Function and (b) not indirectly reachable via inline scopes from any surviving Function and (c) not reachable from a type (i.e.: member functions). Background: I'm currently working on a patch to reverse the pointers between DICompileUnit and DISubprogram (for more info check Duncan's RFC on lazy-loading of debug info metadata http://lists.llvm.org/pipermail/llvm-dev/2016-March/097419.html). The idea is to remove the list of subprograms from DICompileUnit and instead point to the owning compile unit from each DISubprogram. After doing this all DISubprograms fulfilling the above criteria will be implicitly dropped unless we go through an extra effort to preserve them. http://reviews.llvm.org/D18477 <rdar://problem/25256815> llvm-svn: 265876
* Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl2016-03-311-1/+1
| | | | | | | | | | | | | This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder into DICompileUnit. DIBuilder is not the right place for this enum to live in — a metadata consumer should not have to include DIBuilder.h. I also added a Verifier check that checks that the emission kind of a DICompileUnit is actually legal. http://reviews.llvm.org/D18612 <rdar://problem/25427165> llvm-svn: 265077
* Revert "Recommitted r263424 "Supporting all entities declared in lexical ↵Reid Kleckner2016-03-241-112/+32
| | | | | | | | | | | scope in LLVM debug info." After fixing PR26942 (the fix is included in this commit)." This reverts commit r264280. This broke building Chromium for iOS. We'll upload a reproducer to the PR soon. llvm-svn: 264334
* Recommitted r263424 "Supporting all entities declared in lexical scope in ↵Amjad Aboud2016-03-241-32/+112
| | | | | | | | | | LLVM debug info." After fixing PR26942 (the fix is included in this commit). Differential Revision: http://reviews.llvm.org/D18350 llvm-svn: 264280
* Revert "Recommitted r261633 "Supporting all entities declared in lexical ↵Benjamin Kramer2016-03-141-108/+32
| | | | | | | | scope in LLVM debug info." After fixing PR26715 at r263379." This reverts commit r263424. Breaks self-host. llvm-svn: 263437
OpenPOWER on IntegriCloud