summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGDebugInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Debug Info: Pass the pointer size into createMemberPointerType().Adrian Prantl2014-12-231-2/+3
| | | | | | Paired commit with LLVM. llvm-svn: 224781
* Fix a typo.Adrian Prantl2014-12-191-1/+1
| | | | llvm-svn: 224557
* CGDebugInfo: Use DIBuilder API for self-referencing DICompositeTypesDuncan P. N. Exon Smith2014-12-181-9/+10
| | | | | | | | | | | Use new `DIBuilder` API from LLVM r224482 to mutate `DICompositeType`s, rather than changing them directly. This allows `DIBuilder` to track otherwise orphaned cycles when `CollectContainingType()` creates a self-reference. Fixes PR21941. llvm-svn: 224483
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-171-21/+40
| | | | | | | | | Fails an ASan bootstrap - I'll try to reproduce locally & sort that out before recommitting. This reverts commit r224385. llvm-svn: 224441
* DebugInfo: Generalize debug info location handlingDavid Blaikie2014-12-161-40/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 224385
* Fix a GCC error from r223803Duncan P. N. Exon Smith2014-12-091-3/+5
| | | | llvm-svn: 223814
* IR: Update clang for Metadata/Value split in r223802Duncan P. N. Exon Smith2014-12-091-109/+98
| | | | | | Match LLVM API changes from r223802. llvm-svn: 223803
* Debug info for blocks: Fix a bug caught by the Verifier.Adrian Prantl2014-11-211-3/+6
| | | | | | | | | | | | When emitting nested block definitions, the insert-at-point variant of DIBuilder::insertDeclare() could be called with the insertion point set to the end-of-BasicBlock sentinel, causing the parent pointer of the CallInst to be set to the intentionally bogus value of the sentinel. Fixed by conditionally invoking the correct version of insertDeclare(). rdar://problem/19034882 llvm-svn: 222487
* DebugInfo: Fix another case of r222377 when we do have a definition of the ↵David Blaikie2014-11-211-11/+7
| | | | | | variable, but we might not be emitting it (such as templates) llvm-svn: 222485
* Remove now dead code.Frederic Riss2014-11-201-7/+0
| | | | | | | | After LLVM r222434, the Variables field of DISubprograms for forward declarations will always be null. No need to keep code around to delete them. llvm-svn: 222437
* Prepare for the DIBuilder populating DISubprogram's Variables with null.Frederic Riss2014-11-201-1/+2
| | | | | | | | | | | This is a followup to r222373. A better solution to the problem solved there is to not create the leaked nodes at all (we know that they will never be used for forward declared functions anyway). To avoid bot breakage in the interval between the cfe and llvm commits, add a check that the nMDNode is not null before deleting it. This code can completely go away after the LLVM part is in. llvm-svn: 222433
* DebugInfo: Don't emit a 'global variable' when a static member declaration ↵David Blaikie2014-11-191-4/+18
| | | | | | | | | is referenced without a definition, just ensure the enclosing class (with the static member declaration) is emitted. Addresses PR21511 by emitting appropriate metadata rather than faux-global definitions for a variable that doesn't have a definition. llvm-svn: 222377
* Fix a temporary MDNode leak.Frederic Riss2014-11-191-0/+7
| | | | | | | | | | | | While emitting debug information for function forward decalrations, we create DISubprogram objects that aran't stored in the AllSubprograms list, and thus won't get finalized by the DIBuilder. During the DIBuilder finalize(), the temporary MDNode allocated for the DISubprogram Variables field gets RAUWd with a non temporary DIArray. For the forward declarations, simply delete that temporary node before we delete the parent node, so that it doesn't leak. llvm-svn: 222373
* Fully handle globals and functions in CGDebugInfo::getDeclarationOrDefinition()Frederic Riss2014-11-181-11/+83
| | | | | | | | | | | | | | | | | | | | Currently this function would return nothing for functions or globals that haven't seen a definition yet. Make it return a forward declaration that will get RAUWed with the definition if one is seen at a later point. The strategy used to implement this is similar to what's done for types: the forward declarations are stored in a vector and post processed upon finilization to perform the required RAUWs. For now the only user of getDeclarationOrDefinition() is EmitUsingDecl(), thus this patch allows to emit correct imported declarations even in the absence of an actual definition of the imported entity. (Another user will be the debug info generation for argument default values that I need to resurect). Differential Revision: http://reviews.llvm.org/D6173 llvm-svn: 222220
* [DebugInfo] Move collection of various function/var decl properties into ↵Frederic Riss2014-11-181-59/+79
| | | | | | | | helper functions. NFC. Helpers to be re-used in upcoming commit. llvm-svn: 222219
* CGDebugInfo: Update for DIBuilder API changeDuncan P. N. Exon Smith2014-11-151-5/+7
| | | | | | Tracking LLVM commit r222070. llvm-svn: 222071
* PR16091 continued: Debug Info for member functions with undeduced return types.David Blaikie2014-11-111-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type with DW_AT_name "auto", and GCC implements this somewhat, but it presents a few problems to do this with Clang. GCC's implementation only applies to member functions where the auto return type isn't deduced immediately (ie: member functions of templates or member functions defined out of line). In the common case of an inline deduced return type function, GCC emits the DW_AT_type as the deduced return type. Currently GDB doesn't seem to behave too well with this debug info - it treats the return type as 'void', even though the definition of the function has the correctly deduced return type (I guess it sees the return type the declaration has, doesn't understand it, and assumes void). This means the function's ABI might be broken (non-trivial return types, etc), etc. Clang, on the other hand doesn't track this particular case of a deducable return type that is deduced immediately versus one that is deduced 'later'. So if we implement the DWARF5 representation, all deducible return type functions would get adverse GDB behavior (including deduced return type lambda functions, inline deduced return type functions, etc). Also, we can't just do this for auto types that are not deduced - because Clang marks even the declaration's return type as deduced (& provides the underlying type) once a definition is seen that allows the deduction. So we have to ignore even deduced types - but we can't do that for auto variables (because this representation only applies to function declarations - variables and function definitions need the real type so the function can be called, etc) so we'd need to add an extra flag to the type unwrapping/creation code to indicate when we want to see through deduced types and when we don't. It's also not as simple as just checking at the top level when building a function type (for one thing, we reuse the function type building for building function pointer types which might also have 'auto' in them - but be the type of a variable instead) because the auto might be arbitrarily deeply nested ("auto &", "auto (*)()", etc...) So, with all that said, let's do the simple thing that works in existing debuggers for now and treat these functions the same way we do function templates and implicit special members: omit them from the member list, since they can't be correctly called anyway (without knowing the return type the ABI isn't know and a function call could put the arguments in the wrong place) so they're not much use to the user. At some point in the future, when GDB understands the DWARF5 representation better it might be worth plumbing through the extra type builder handling to avoid looking through AutoType for some callers, etc... llvm-svn: 221704
* Return a DIDescriptor from CGDebugInfo::getDeclarationOrDefinition...Frederic Riss2014-11-061-3/+3
| | | | | | | ... instead of a DIScope that might wrap something that's not actually a DIScope (eg. a DIGlobalVariable); llvm-svn: 221481
* [DebugInfo] Do not record artificial global initializer functions in the ↵Frederic Riss2014-11-051-1/+4
| | | | | | | | | | | | | | | DeclCache. When we are generating the global initializer functions, we call CGDebugInfo::EmitFunctionStart() with a valid decl which is describing the initialized global variable. Do not update the DeclCache with this key as it will overwrite the the cached variable DIGlobalVariable with the newly created artificial DISubprogram. One could wonder if we should put artificial subprograms in the DIE tree at all (there are vaild uses for them carrying line information though). llvm-svn: 221385
* Debug info: Emit the correct type for the __FuncPtr field in a blockAdrian Prantl2014-11-051-2/+4
| | | | | | | | descriptor. rdar://problem/15984431 llvm-svn: 221326
* Fix 80-column and other odd formatting.Eric Christopher2014-10-261-427/+388
| | | | llvm-svn: 220659
* CodeGen: GLValue exprs in template parameters should have reference typeDavid Majnemer2014-10-241-0/+2
| | | | | | | | This fixes a corner-case where __uuidof as a template argument would result in us trying to emit a GLValue as an RValue. This would lead to a crash down the road. llvm-svn: 220585
* DebugInfo: Correctly describe the lexical decl context of static member ↵David Blaikie2014-10-231-2/+9
| | | | | | | | | | | | | | | | | | variable definitions. The previous IR representation used the non-lexical decl context, which placed the definitions in the same scope as the declarations (ie: within the class) - this was hidden by the fact that LLVM currently doesn't respect the context of global variable definitions at all, and always puts them at the top level (as direct children of the compile_unit). Having the correct lexical scope improves source fidelity and simplify backend global variable emission (with changes coming shortly). Doing something similar for non-member global variables would help simplify/cleanup things further (see FIXME in the commit) and provide similar source fidelity benefits to the final debug info. llvm-svn: 220488
* DebugInfo: Omit scopes in -gmlt to reduce metadata size (on disk and in memory)David Blaikie2014-10-221-5/+14
| | | | | | | I haven't done any actual impact analysis of this change as it's a strict improvement, but I'd be curious to know how much it helps. llvm-svn: 220408
* Fix whitespace introduced in r220221David Blaikie2014-10-201-1/+1
| | | | | | Post commit review feedback from Yaron Keren. llvm-svn: 220229
* PR21312: Fix a regression in non-type template parameters of function type ↵David Blaikie2014-10-201-2/+3
| | | | | | that are static member functions. llvm-svn: 220221
* Fix indentation.David Blaikie2014-10-201-1/+1
| | | | llvm-svn: 220216
* PR21305: Typedefs in non-type template parameters in member data pointers.David Blaikie2014-10-181-1/+1
| | | | | | Patch by Stephen Crane! llvm-svn: 220122
* Rename TemplateArgument::getTypeForDecl to getParamTypeForDecl for clarityDavid Blaikie2014-10-171-9/+6
| | | | | | Code review feedback from Richard Smith on r219900. llvm-svn: 220060
* PR21246: DebugInfo: Emit the appropriate type (cv qualifiers, ↵David Blaikie2014-10-161-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | reference-ness, etc) for non-type template parameters Plumb through the full QualType of the TemplateArgument::Declaration, as it's insufficient to only know whether the type is a reference or pointer (that was necessary for mangling, but insufficient for debug info). This shouldn't increase the size of TemplateArgument as TemplateArgument::Integer is still longer by another 32 bits. Several bits of code were testing that the reference-ness of the parameters matched, but this seemed to be insufficient (various other features of the type could've mismatched and wouldn't've been caught) and unnecessary, at least insofar as removing those tests didn't cause anything to fail. (Richard - perchaps you can hypothesize why any of these checks might need to test reference-ness of the parameters (& explain why reference-ness is part of the mangling - I would've figured that for the reference-ness to be different, a prior template argument would have to be different). I'd be happy to add them in/beef them up and add test cases if there's a reason for them) llvm-svn: 219900
* DebugInfo: Lazily built static member variable declarations should use the ↵David Blaikie2014-10-141-0/+1
| | | | | | | | | | | | | | canonical declaration for line/file information. When lazily constructing static member variable declarations (when the vtable optimization fires and the definition of the type is omitted (or built later, lazily), but the out of line definition of the static member is provided and must be described in debug info) ensure we use the canonical declaration when computing the file, line, etc for that declaration (rather than the definition, which is also a declaration, but not the canonical one). llvm-svn: 219736
* Using an explicit cast to work around MSVC 2013 not picking the conversion ↵Aaron Ballman2014-10-061-1/+1
| | | | | | operator as expected. NFC, should fix the MSVC build bots. llvm-svn: 219116
* Add FIXME/notes to the future.David Blaikie2014-10-061-0/+5
| | | | llvm-svn: 219104
* DebugInfo: Don't include implicit special members in the list of class membersDavid Blaikie2014-10-061-18/+17
| | | | | | | | By leaving these members out of the member list, we avoid them being emitted into type unit definitions - while still allowing the definition/declaration to be injected into the compile unit as expected. llvm-svn: 219101
* DebugInfo: Don't include member function template specializations in the ↵David Blaikie2014-10-061-10/+0
| | | | | | | | | | list of class members By leaving these members out of the member list, we avoid them being emitted into type unit definitions - while still allowing the definition/declaration to be injected into the compile unit as expected. llvm-svn: 219100
* DIBuilder: Encapsulate DIExpression's element typeDuncan P. N. Exon Smith2014-10-011-18/+16
| | | | | | | Update for corresponding LLVM API change for `DIBuilder::createExpression()`. llvm-svn: 218798
* Update CGDebugInfo to the updated API in LLVM.Adrian Prantl2014-10-011-21/+25
| | | | | | | | | | Complex address expressions are no longer part of DIVariable, but rather an extra argument to the debug intrinsics. http://reviews.llvm.org/D4919 rdar://problem/17994491 llvm-svn: 218788
* Reverting r218777 while investigating buildbot breakage.Adrian Prantl2014-10-011-25/+21
| | | | | | "Update CGDebugInfo to the updated API in LLVM." llvm-svn: 218781
* Update CGDebugInfo to the updated API in LLVM.Adrian Prantl2014-10-011-21/+25
| | | | | | | | | | Complex address expressions are no longer part of DIVariable, but rather an extra argument to the debug intrinsics. http://reviews.llvm.org/D4919 rdar://problem/17994491 llvm-svn: 218777
* Remove dead code from DIBuilderJyoti Allur2014-09-291-3/+3
| | | | llvm-svn: 218593
* Include debug info for types referenced only via explicit cast expressions.David Blaikie2014-09-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Most of the debug info emission is powered essentially from function definitions - if we emit the definition of a function, we emit the types of its parameters, the members of those types, and so on and so forth. For types that aren't referenced even indirectly due to this - because they only appear in temporary expressions, not in any named variable, we need to explicitly emit/add them as is done here. This is not the only case of such code, and we might want to consider handling "void func(void*); ... func(new T());" (currently debug info for T is not emitted) at some point, though GCC doesn't. There's a much broader solution to these issues, but it's a lot of work for possibly marginal gain (but might help us improve the default -fno-standalone-debug behavior to be even more aggressive in some places). See the original review thread for more details. Patch by jyoti allur (jyoti.yalamanchili@gmail.com)! Differential Revision: http://reviews.llvm.org/D2498 llvm-svn: 218390
* Debug info: Only emit C++ accessibility specifiers when they are divergingAdrian Prantl2014-08-291-37/+46
| | | | | | | | from the default for the containing type. rdar://problem/18154959 llvm-svn: 216800
* [C++11] Support for capturing of variable length arrays in lambda expression.Alexey Bataev2014-08-281-2/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D4368 llvm-svn: 216649
* Update for LLVM API change to remove discriminator tracking from ↵David Blaikie2014-08-211-2/+1
| | | | | | DILexicalBlock (in favor of DILexicalBlockFile - where a default arg is used to avoid the need for API churn of those callers) llvm-svn: 216240
* Debuginfo: Correctly tag variadic ObjC methods with ↵Frederic Riss2014-08-121-0/+3
| | | | | | | | DW_TAG_unspecified_parameter. Fixes rdar://13690847 llvm-svn: 215423
* DebugInfo: Blocks: Do not depend on LLVM argument numbering when choosing ↵David Blaikie2014-08-081-1/+2
| | | | | | | | | | | | the debug info argument numbering. Due to the possible presence of return-by-out parameters, using the LLVM argument number count when numbering debug info arguments can end up off-by-one. This could produce two arguments with the same number, which would in turn cause LLVM to emit only one of those arguments (whichever it found last) or assert (r215157). llvm-svn: 215227
* Debug info: Use the vbtable offset for virtual bases in the MS ABIReid Kleckner2014-08-071-5/+12
| | | | | | | | There are no vtable offset offsets in the MS ABI, but vbtable offsets are analogous. There are no consumers of this information yet, but at least we don't crash now. llvm-svn: 215149
* Revert "Debug info: Use record layout to find vbase offsets instead of vtables"Reid Kleckner2014-08-071-1/+3
| | | | | | | | | This reverts commit r215137. This doesn't work at all, an offset-offset is probably different than an offset. I'm scared that this passed our normal test suite. llvm-svn: 215141
* Debug info: Use record layout to find vbase offsets instead of vtablesReid Kleckner2014-08-071-3/+1
| | | | | | | | | This fixes an assertion when generating full debug info in the MS ABI for classes with virtual bases. Fixes PR20579. llvm-svn: 215137
* MS ABI: Consider alignment attributes on typedefs for layoutDavid Majnemer2014-07-301-11/+13
| | | | | | | | | | | | | | | | | | | The MS ABI has a notion of 'required alignment' for fields; this alignment supercedes pragma pack directives. MSVC takes into account alignment attributes on typedefs when determining whether or not a field has a certain required alignment. Do the same in clang by tracking whether or not we saw such an attribute when calculating the type's bitwidth and alignment. This fixes PR20418. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D4714 llvm-svn: 214274
OpenPOWER on IntegriCloud