summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGDebugInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* [Debug Info] add DISubroutineType and its creation takes DITypeArray.Manman Ren2014-07-281-8/+9
| | | | | | | This is the last patch to unique the type array of a subroutine type. This is the paired commit with llvm r214132. llvm-svn: 214133
* [Debug Info] rename getTypeArray to getElements, setTypeArray to setArrays.Manman Ren2014-07-281-6/+6
| | | | | | This is the paired commit with llvm r214112. llvm-svn: 214113
* Add new debug kind LocTrackingOnly.Diego Novillo2014-06-241-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This new debug emission kind supports emitting line location information in all instructions, but stops code generation from emitting debug info to the final output. This mode is useful when the backend wants to track source locations during code generation, but it does not want to produce debug info. This is currently used by optimization remarks (-Rpass, -Rpass-missed and -Rpass-analysis). When one of the -Rpass flags is used, the front end will enable location tracking, only if no other debug option is enabled. To prevent debug information from being generated, a new debug info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to not emit the llvm.dbg.cu annotation. This blocks final code generation from generating debug info in the back end. Depends on D4234. Reviewers: echristo, dblaikie Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4235 llvm-svn: 211610
* Delete apparently unused methodAlexey Samsonov2014-06-021-26/+0
| | | | llvm-svn: 210047
* CGDebugInfo: Simplify/invert createLexicalBlock parameter construction.David Blaikie2014-06-021-8/+5
| | | | llvm-svn: 210033
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-14/+14
| | | | llvm-svn: 209272
* DebugInfo: Avoid creating DILexicalScopeFiles when the filename in the ↵David Blaikie2014-05-141-7/+11
| | | | | | | | | | | | | | | | | | | current scope has not changed. This looks like the right way for this check to work, but there is another semi-obvious bug, I would think: why is CurLoc not zero'd out between functions? The possibility for it to bleed between them seems problematic. (& indeed I caused tests to fail when I fixed this a different way, by setting CurLoc to SourceLocation() and the end of EmitFunctionEnd... ) The changes to debug-info-blocks.m are due to a mismatch between the source manager's file naming and CGDebugInfo's default handling when no -main-file-name is specified. This actually reveals somewhat of a bug in the debug info when using source files from standard in, too. See the comment in CGDebugInfo::CreateCompileUnit for more details. llvm-svn: 208742
* Decouple ExprCXX.h and DeclCXX.h and clean up includes a bit.Benjamin Kramer2014-05-101-1/+1
| | | | | | | Required pulling LambdaExpr::Capture into its own header. No functionality change. llvm-svn: 208470
* PR19562: Fix another temporary node leak in Clang debug info emissionDavid Blaikie2014-05-071-10/+10
| | | | | | | | | | | | | | While constructing ObjC Interface types we might create the declaration of some normal C++ types, thus adding things to the ReplaceMap. Make sure we process the ReplaceMap after the ObjC interfaces. In theory we know at this point, since we're at the end of the TU, that we won't be upgrading any declarations to definitions, so we could just construct non-temporary nodes, but that would require extra state in CGDebugInfo to conditionalize the creation of declaration nodes which seems annoying/more work than is appropriate. llvm-svn: 208226
* DebugInfo: Use enum instead of unsignedEd Maste2014-05-071-8/+8
| | | | | | | | This makes debuging DebugInfo generation with LLDB a little more pleasant. Differential Revision: http://reviews.llvm.org/D3626 llvm-svn: 208203
* PR19562: Fix memory leak when ObjC interface types cause the creation of ↵David Blaikie2014-05-071-1/+5
| | | | | | further interfaces. llvm-svn: 208161
* Reapply: DebugInfo: Emit the definition of enums when the definition ↵David Blaikie2014-05-061-0/+29
| | | | | | | | | | | | | | | | | | | preceeds the declaration and initial use. Reverting r208106 to reapply r208065 with a fix for the regression. The issue was that the enum tried to be built even if the declaration hadn't been constructed for debug info - presenting problems for enum templates and typedefs of enums with names for linkage purposes. Original commit message: This regressed a little further 208055 though it was already a little broken. While the requiresCompleteType optimization should be implemented here. Future (possibly near future) work. llvm-svn: 208114
OpenPOWER on IntegriCloud