summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix typosAlp Toker2014-06-071-1/+1
| | | | llvm-svn: 210401
* DebugInfo: Use the scope of the function declaration, if any, to name a ↵David Blaikie2014-06-061-0/+7
| | | | | | | | | | function in DWARF pubnames This ensures that member functions, for example, are entered into pubnames with their fully qualified name, rather than inside the global namespace. llvm-svn: 210379
* DebugInfo: pubnames: include file-local (static or anonymous namespace) ↵David Blaikie2014-06-061-9/+10
| | | | | | | | | variables and anonymous namespaces themselves. Still some issues with name qualification, FIXMEs added to test cases and fixes will come next. llvm-svn: 210378
* Revert r210221 again, due to a crash Richard Smith has provided involving ↵David Blaikie2014-06-051-2/+1
| | | | | | | | self-hosting LLVM with libc++. Test case coming, once I reduce it. llvm-svn: 210236
* DebugInfo: Add comments/assert description to r209674 based on Eric ↵David Blaikie2014-06-051-2/+4
| | | | | | Christopher's post-commit review feedback. llvm-svn: 210228
* DebugInfo: Reapply r209984 (reverted in r210143), asserting that abstract ↵David Blaikie2014-06-041-5/+3
| | | | | | | | | | | | | | | | | DbgVariables have DIEs. Abstract variables within abstract scopes that are entirely optimized away in their first inlining are omitted because their scope is not present so the variable is never created. Instead, we should ensure the scope is created so the variable can be added, even if it's been optimized away in its first inlining. This fixes the incorrect debug info in missing-abstract-variable.ll (added in r210143) and passes an asserts self-hosting build, so hopefully there's not more of these issues left behind... *fingers crossed*. llvm-svn: 210221
* DebugInfo: Partial revert r209984 due to more cases where abstract ↵David Blaikie2014-06-041-1/+5
| | | | | | | | | | | | | | | DbgVariables do not have associated DIEs. Along with a test case to demonstrate that due to inlining order there are cases where abstract variable DIEs are not constructed since the abstract subprogram was built due to a previous inlining that optimized away those variables. This produces incorrect debug info (the 'missing' abstract variable causes the inlined instance of that variable to be emitted with a full description (name, line, file) rather than referencing the abstract origin), but this commit at least ensures that it doesn't crash... llvm-svn: 210143
* DebugInfo: Assert that DbgVariables have associated DIEsDavid Blaikie2014-06-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
* Fix typosAlp Toker2014-05-311-1/+1
| | | | llvm-svn: 209982
* DebugInfo: partially revert cleanup committed in r209680David Blaikie2014-05-271-1/+2
| | | | | | | | | | I'm not sure exactly where/how we end up with an abstract DbgVariable with a null DIE, but we do... looking into it & will add a test and/or fix when I figure it out. Currently shows up in selfhost or compiler-rt builds. llvm-svn: 209683
* DebugInfo: Simplify solution to avoid DW_AT_artificial on inlined parameters.David Blaikie2014-05-271-13/+9
| | | | | | | Originally committed in r207717, I clearly didn't look very closely at the code to understand how existing things were working... llvm-svn: 209680
* DebugInfo: Lazily attach definition attributes to definitions.David Blaikie2014-05-271-1/+7
| | | | | | | | | | | | | | | | | | | | | This is a precursor to fixing inlined debug info where the concrete, out-of-line definition may preceed any inlined usage. To cope with this, the attributes that may appear on the concrete definition or the abstract definition are delayed until the end of the module. Then, if an abstract definition was created, it is referenced (and no other attributes are added to the out-of-line definition), otherwise the attributes are added directly to the out-of-line definition. In a couple of cases this causes not just reordering of attributes, but reordering of types. When the creation of the attribute is delayed, if that creation would create a type (such as for a DW_AT_type attribute) then other top level DIEs may've been constructed during the delay, causing the referenced type to be created and added after those intervening DIEs. In the extreme case, in cross-cu-inlining.ll, this actually causes the DW_TAG_basic_type for "int" to move from one CU to another. llvm-svn: 209674
* DebugInfo: Separate out the addition of subprogram attribute additions so ↵David Blaikie2014-05-271-9/+15
| | | | | | that they can be added later depending on whether or not the function is inlined. llvm-svn: 209673
* DwarfUnit: Remove some misleading no-op code introduced in r204162.David Blaikie2014-05-261-4/+0
| | | | | | | Post commit review feedback from Manman called this out, but it looks like it slipped through the cracks. llvm-svn: 209611
* DebugInfo: Simplify subprogram declaration creation/references and ↵David Blaikie2014-05-211-21/+18
| | | | | | | | accidentally refix PR11300. Also simplifies the linkage name handling a little too. llvm-svn: 209311
* Unbreak the sanitizer buildbots after r209226 due to SROA issue described in ↵David Blaikie2014-05-201-4/+7
| | | | | | | | | | | | | | | http://reviews.llvm.org/D3714 Undecided whether this should include a test case - SROA produces bad dbg.value metadata describing a value for a reference that is actually the value of the thing the reference refers to. For now, loosening the assert lets this not assert, but it's still bogus/wrong output... If someone wants to tell me to add a test, I'm willing/able, just undecided. Hopefully we'll get SROA fixed soon & we can tighten up this assertion again. llvm-svn: 209240
* Fix test breakage introduced in r209223.David Blaikie2014-05-201-1/+2
| | | | | | Oops, broke the broken enum constants again. llvm-svn: 209226
* PR19767: DebugInfo emission of pointer constants.David Blaikie2014-05-201-2/+13
| | | | | | | | | | | | | | | | | In refactoring DwarfUnit::isUnsignedDIType I restricted it to only work on values with signedness (unsigned or signed), asserting on anything else (which did uncover some bugs). But it turns out that we do need to emit constants of signless data, such as pointer constants - only null pointer constants are known to need this so far, but it's conceivable that there might be non-null pointer constants at some point (hardcoded address offsets for device drivers?). This patch just uses 'unsigned' for signless data such as pointer constants. Arguably we could use signless representations (DW_FORM_dataN) instead, allowing a trinary result from isUnsignedDIType (signed, unsigned, signless), but this seems reasonable for now. llvm-svn: 209223
* DebugInfo: Handle emitting constants of C++ unicode character type.David Blaikie2014-05-161-2/+3
| | | | | | | | Patch by Stephan Tolksdorf! (with some test case stuff by me) Differential Revision: http://reviews.llvm.org/D3810 llvm-svn: 209037
* CodeGen: add parenthesis around complex expressionSaleem Abdulrasool2014-05-121-5/+5
| | | | | | Add missing parenthesis suggested by GCC. NFC. llvm-svn: 208519
* DwarfUnit: Make explicit a limitation/bug in enumeration constant emission.David Blaikie2014-05-111-4/+9
| | | | | | | | Filed as PR19712, LLVM fails to detect the right type of an enum constant when a frontend does not provide an underlying type for the enumeration type. llvm-svn: 208502
* DwarfUnit: Pick a winner between isTypeSigned and isUnsignedDIType.David Blaikie2014-05-111-23/+16
| | | | | | | | | And the winner by a nose is isUnsignedDIType, for no particular reason. These two functions were just complements of each other and used in very related code, so refactor callers to just use one of them. llvm-svn: 208500
* DwarfUnit: Factor out calling isUnsignedDIType into a utility function so ↵David Blaikie2014-05-111-8/+10
| | | | | | each caller of emitConstantValue doesn't have to call it separately. llvm-svn: 208496
* DwarfUnit: Share common constant value emission between APInts of small (<= ↵David Blaikie2014-05-111-40/+16
| | | | | | | | | | | | 64 bit) and MCOperand immediates. Doesn't seem a good reason to duplicate this code (it was more literally duplicated prior to r208494, and while the dataN code /does/ actually fire in this case, it doesn't seem necessary (and the DWARF standard recommends using udata/sdata pervasively instead of dataN, so as to indicate signedness of the values)) llvm-svn: 208495
* DebugInfo: Simplify constant value emission.David Blaikie2014-05-111-41/+11
| | | | | | | | | | | | | This code looks to have become dead at some time in the past. I tried to reproduce cases where LLVM would emit constants with dataN, but could not. Upon inspection it seems the code doesn't do that anymore - the only time a size is provided by isTypeSigned is when the type is signed, and in those cases we use sdata. dataN is only used for unsigned types and isTypeSigned doesn't provide a value for sizeInBits in that case. Remove the dead cases/size plumbing. llvm-svn: 208494
* Revert "Emit DW_AT_object_pointer once, on the declaration, for each function."David Blaikie2014-04-301-7/+2
| | | | | | | | | | | | | | Breaks GDB buildbot (http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/14517) GCC emits DW_AT_object_pointer /everywhere/ (declaration, abstract definition, inlined subroutine), but it looks like GCC relies on it being somewhere other than the declaration, at least. I'll experiment further & can hopefully still remove it from the inlined_subroutine. This reverts commit r207705. llvm-svn: 207719
* DebugInfo: Omit DW_AT_artificial on DW_TAG_formal_parameters in ↵David Blaikie2014-04-301-6/+7
| | | | | | | | | | | | DW_TAG_inlined_subroutines. They just don't need to be there - they're inherited from the abstract definition. In theory I would like them to be inherited from the declaration, but the DWARF standard doesn't quite say that... we can probably do it anyway but I'm less confident about that so I'll leave it for a separate commit. llvm-svn: 207717
* Emit DW_AT_object_pointer once, on the declaration, for each function.David Blaikie2014-04-301-2/+7
| | | | | | | | | | | | | | | | This effectively reverts r164326, but adds some comments and justification and ensures we /don't/ emit the DW_AT_object_pointer on the (abstract and concrete) definitions. (while still preserving it on standalone definitions involving ObjC Blocks) This does increase the size of member function declarations from 7 to 11 bytes, unfortunately, but still seems like the Right Thing to do so that callers that see only the declaration still have the information about the object pointer. That said, I don't know what, if any, DWARF consumers don't have a heuristic to guess this in the case of normal C++ member functions - perhaps we can remove it entirely. llvm-svn: 207705
* Remove DwarfUnit::LabelRange since it's unused.David Blaikie2014-04-281-1/+0
| | | | | | | | | | | Seems at some point the intent was to emit fission ranges_base as unique per CU but the code today emits ranges_base as the start of the ranges section for all CUs being compiled and all the ranges_base relative addresses are relative to that. So removing this dead code and leaving the status quo until there's a reason to change it (perhaps something's faster if it has distinct ranges for each CU). llvm-svn: 207464
* DebugInfo: Just store the DIE by value in the DwarfUnitDavid Blaikie2014-04-281-20/+21
| | | | | | | | | Since all 4 ctor calls in DwarfDebug just pass in a trivially constructed DIE with the right tag type, sink the tag selection down into the Dwarf*Unit ctors (removing the argument entirely from callers in DwarfDebug) and initialize the DIE member in DwarfUnit. llvm-svn: 207448
* Pass DIEs to DwarfUnit constructors by unique_ptr.David Blaikie2014-04-281-12/+13
| | | | llvm-svn: 207447
* DwarfDebug: Minor refactoring around type unit constructionDavid Blaikie2014-04-261-0/+6
| | | | | | | | | | | | | Sinking addition of the declaration attribute down to where the signature is added. So that if the signature is not added neither is the declaration attribute (this will come in handy when aborting type unit construction to instead emit the type into the CU directly in some cases) Pull out type unit identifier hashing just to simplify the function a little, it'll be getting longer. llvm-svn: 207321
* Encapsulate the DWARF string pool in a separate type.David Blaikie2014-04-251-3/+3
| | | | | | | | | Pulls out some more code from some of the rather monolithic DWARF classes. Unlike the address table, the string table won't move up into DwarfDebug - each DWARF file has its own string table (but there can be only one address table). llvm-svn: 207277
* DIE: Pass ownership of children via std::unique_ptr rather than raw pointer.David Blaikie2014-04-251-5/+6
| | | | | | | | | | | This should reduce the chance of memory leaks like those fixed in r207240. There's still some unclear ownership of DIEs happening in DwarfDebug. Pushing unique_ptr and references through more APIs should help expose the cases where ownership is a bit fuzzy. llvm-svn: 207263
* DIEEntry: Refer to the specified DIE via reference rather than pointer.David Blaikie2014-04-251-12/+12
| | | | | | | Makes some more cases (the unit tests, specifically), lexically compatible with a change to unique_ptr. llvm-svn: 207261
* DwarfUnit: return by reference from createAndAddDIEDavid Blaikie2014-04-251-32/+32
| | | | | | | Since this doesn't return ownership (the DIE has been added to the specified parent already) nor return null, just return by reference. llvm-svn: 207259
* Return DIE by reference instead of pointer from DwarfUnit::getUnitDieDavid Blaikie2014-04-251-3/+3
| | | | llvm-svn: 207255
* DwarfUnit: Suddently, DIE references, everywhere.David Blaikie2014-04-251-216/+207
| | | | | | | | This'll make changing to unique_ptr ownership of DIEs easier since the usages will now have '*' on them making them textually compatible between unique_ptr and raw pointer. llvm-svn: 207253
* Refactor some common logic in DwarfUnit::constructVariableDIE and pass ↵David Blaikie2014-04-251-16/+18
| | | | | | non-null DIE by reference to DbgVariable::setDIE llvm-svn: 207244
* [C++] Use 'nullptr'.Craig Topper2014-04-241-13/+14
| | | | llvm-svn: 207083
* Remove the intermediate AccelTypes maps in DWARF units.David Blaikie2014-04-241-10/+1
| | | | llvm-svn: 207060
* Remove the intermediate AccelNamespace maps in DWARF units.David Blaikie2014-04-241-10/+2
| | | | llvm-svn: 207059
* Remove the intermediate AccelObjC maps in DWARF unitsDavid Blaikie2014-04-241-8/+0
| | | | llvm-svn: 207057
* Remove intermediate accelerator table for names.David Blaikie2014-04-231-14/+2
| | | | | | (similar changes coming for the other accelerator tables) llvm-svn: 207049
* Move the AddressPool from DwarfFile to DwarfDebug.David Blaikie2014-04-231-3/+3
| | | | | | | | | There's only ever one address pool, not one per DWARF output file, so let's just have one. (similar refactoring of the string pool to come soon) llvm-svn: 207026
* Separate out the DWARF address pool into its own type/files.David Blaikie2014-04-231-3/+4
| | | | llvm-svn: 207022
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-2/+2
| | | | | | | | | | | | define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
* Re-apply r206096 after investigating the gdb buildbot failure.Adrian Prantl2014-04-141-9/+14
| | | | | | | | | | | | | | | Thanks to dblaikie for updating the testcase! Debug info: (bugfix) C++ C/Dtors can be compiled to multiple functions, therefore, their declaration cannot have one DW_AT_linkage_name. The specific instances however can and should have that attribute. This patch reorders the code in DwarfUnit::getOrCreateSubprogramDIE() to emit linkage names for C/Dtors. rdar://problem/16362674. llvm-svn: 206210
* PR13337: Omit DW_TAG_restrict_type when compiling for DWARF2David Blaikie2014-04-121-0/+4
| | | | | | | DWARF3 introduced DW_TAG_restrict_type, so avoid using it in prior versions. llvm-svn: 206105
* Revert "Debug info: (bugfix) C++ C/Dtors can be compiled to multiple functions,"Adrian Prantl2014-04-121-14/+9
| | | | | | | This reverts commit 206096 while I investigate why this broke the gdb buildbot. llvm-svn: 206103
OpenPOWER on IntegriCloud