summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Use dwarf::Tag rather than unsigned for DIE::Tag to make debugging easier.David Blaikie2014-04-121-1/+3
| | | | | | | | | | | Nice to be able to just print out the Tag and have the debugger print dwarf::DW_TAG_subprogram or whatever, rather than an int. It's a bit finicky (for example DIDescriptor::getTag still returns unsigned) because some places still handle real dwarf tags + our fake tags (one day we'll remove the fake tags, hopefully). llvm-svn: 206098
* Debug info: (bugfix) C++ C/Dtors can be compiled to multiple functions,Adrian Prantl2014-04-121-9/+14
| | | | | | | | | | | | 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: 206096
* DebugInfo: Use a 64 bit type for the subrangeDavid Blaikie2014-04-031-4/+4
| | | | | | | | | | | While we were encoding 64 bit values (data8) in the subrange itself, using a 32 bit type for the subrange was still confusing the gdb. Oh, and make it unsigned too. As the comment points out, this could be pushed into the frontend so that it would be 32 or 64 bit as appropriate, etc. llvm-svn: 205512
* Adjust comments regarding non-relocated abbrev offset in debug_info.dwoDavid Blaikie2014-04-021-1/+1
| | | | | | | | I'm not sure the comment in the implementation really adds a lot of value (it's clear that we emit zero when no symbol is provided, but it doesn't explain why we would do that). Happy to iterate. llvm-svn: 205386
* DebugInfo: Avoid creating unnecessary/empty line tables and remove the ↵David Blaikie2014-04-011-11/+2
| | | | | | | | | | | | special case of '0' in DwarfCompileUnit::initStmtList by just always using a label difference This moves one case of raw text checking down into the MCStreamer interfaces in the form of a virtual function, even if we ultimately end up consolidating on the one-or-many line tables issue one day, this is nicer in the interim. This just generally streamlines a bunch of use cases into a common code path. llvm-svn: 205287
* Get rid of an unnecessary use of the * and & operators.Adrian Prantl2014-03-241-1/+1
| | | | llvm-svn: 204673
* DebugInfo: Don't emit relocations to abbreviations in debug_info.dwoDavid Blaikie2014-03-241-1/+5
| | | | llvm-svn: 204667
* Remove unused parameterDavid Blaikie2014-03-241-5/+3
| | | | llvm-svn: 204663
* Reapply DW_AT_low/high_pc patch:Eric Christopher2014-03-201-12/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the range machinery for DW_AT_ranges and DW_AT_high/lo_pc. This commit moves us from a single range per subprogram to extending ranges if we are: a) In the same section, and b) In the same enclosing CU. This means we have more fine grained ranges for compile units, and fewer ranges overall when we have multiple functions in the same CU adjacent to each other in the object file. Also remove all of the earlier hacks around this functionality for function sections etc. Also update all of the testcases to take into account the merging functionality. with a fix for location entries in the debug_loc section: Make sure that debug loc entries are relative to the low_pc of the compile unit. This means that when we only have a single range that the offset should be just relative to the low_pc of the unit, for multiple ranges for a CU this means that we'll be relative to 0 which we emit along with DW_AT_ranges. This mostly shows up with linked binaries, so add a testcase with multiple CUs so that our location is going to be offset of a CU with a non-zero low_pc. llvm-svn: 204377
* Revert "Use the range machinery for DW_AT_ranges and DW_AT_high/lo_pc."Eric Christopher2014-03-201-42/+12
| | | | | | | | This appears to trigger failures with optimization and function arguments somehow. This reverts commit r204277. llvm-svn: 204286
* Use the range machinery for DW_AT_ranges and DW_AT_high/lo_pc.Eric Christopher2014-03-191-12/+42
| | | | | | | | | | | | | | | | | | This commit moves us from a single range per subprogram to extending ranges if we are: a) In the same section, and b) In the same enclosing CU. This means we have more fine grained ranges for compile units, and fewer ranges overall when we have multiple functions in the same CU adjacent to each other in the object file. Also remove all of the earlier hacks around this functionality for function sections etc. Also update all of the testcases to take into account the merging functionality. llvm-svn: 204277
* Debug info: Remove OdrMemberMap from DwarfDebug, it's not necessary.Adrian Prantl2014-03-181-19/+3
| | | | | | Follow-up to r203982. llvm-svn: 204162
OpenPOWER on IntegriCloud