summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGDebugInfo.h
Commit message (Collapse)AuthorAgeFilesLines
* Put back doxygen comment accidentally dropped in r250418.Benjamin Kramer2015-10-151-0/+5
| | | | llvm-svn: 250428
* [CodeGen] Remove dead code. NFC.Benjamin Kramer2015-10-151-19/+0
| | | | llvm-svn: 250418
* Support Debug Info path remappingSaleem Abdulrasool2015-10-121-0/+5
| | | | | | | | | | | | | | | | Add support for the `-fdebug-prefix-map=` option as in GCC. The syntax is `-fdebug-prefix-map=OLD=NEW`. When compiling files from a path beginning with OLD, change the debug info to indicate the path as start with NEW. This is particularly helpful if you are preprocessing in one path and compiling in another (e.g. for a build cluster with distcc). Note that the linearity of the implementation is not as terrible as it may seem. This is normally done once per file with an expectation that the map will be small (1-2) entries, making this roughly linear in the number of input paths. Addresses PR24619. llvm-svn: 250094
* Fix Clang-tidy modernize-use-nullptr warnings in headers and generated ↵Hans Wennborg2015-09-291-2/+2
| | | | | | | | | | files; other minor cleanups. By Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13187 llvm-svn: 248828
* Debug Info: Use the module pointer as key for the module cache.Adrian Prantl2015-09-241-1/+1
| | | | | | This way we don't need to rebuild the full module name for every decl. llvm-svn: 248510
* Module Debugging: Use the clang module signature as the module's dwo_idAdrian Prantl2015-09-221-0/+3
| | | | | | | | | | | when building a module. Clang already records the module signature when building a skeleton CU to reference a clang module. Matching the id in the skeleton with the one in the module allows a DWARF consumer to verify that they found the correct version of the module without them needing to know about the clang module format. llvm-svn: 248345
* Module debugging: Support submodules in the PCM/PCH debug info.Adrian Prantl2015-09-201-3/+10
| | | | llvm-svn: 248127
* CGDebugInfo: Make creating a skeleton CU in getOrCreateModuleRef optional.Adrian Prantl2015-09-181-2/+4
| | | | | | | | | We don't want a skeleton CU when generating debug info for the module itself. NFC. llvm-svn: 248062
* Debug Info: Use the full module name as a key when caching DIModules.Adrian Prantl2015-09-181-2/+2
| | | | | | | | | | | The signature may not have been computed at the time the module reference is generated (e.g.: in the future while emitting debug info for a clang module). Using the full module name is safe because each clang module may only have a single definition. NFC. llvm-svn: 248037
* [OpenCL] Add new types for OpenCL 2.0.Alexey Bader2015-09-151-0/+10
| | | | | | | | Patch by Pedro Ferreira. Reviewers: pekka.jaaskelainen Differential Revision: http://reviews.llvm.org/D12855 llvm-svn: 247676
* Module Debugging: Emit forward declarations for types that are defined inAdrian Prantl2015-09-111-0/+3
| | | | | | | | | clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified. This reimplements r247369 in about a third of the amount of code. Thanks to David Blaikie pointing this out in post-commit review! llvm-svn: 247432
* Revert "Module Debugging: Emit forward declarations for types that are ↵Adrian Prantl2015-09-111-9/+0
| | | | | | | | defined in" This reverts commit r247369 to facilitate reviewing of the following patch. llvm-svn: 247431
* Module Debugging: Emit forward declarations for types that are defined inAdrian Prantl2015-09-111-0/+9
| | | | | | clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified. llvm-svn: 247369
* Cleanup: Let CGDebugInfo::ModuleRefCache use a TrackingMDNode (NFC).Adrian Prantl2015-09-111-1/+1
| | | | llvm-svn: 247368
* Add a getDeclContextDescriptor() helper function to CGDebugInfo. (NFC)Adrian Prantl2015-09-101-2/+5
| | | | llvm-svn: 247319
* Module Debugging: Emit debug type information into clang ObjC modules.Adrian Prantl2015-09-081-0/+3
| | | | | | | | | | When -fmodule-format is set to "obj", emit debug info for all types declared in a module or referenced by a declaration into the module's object file container. This patch adds support for Objective-C types and methods. llvm-svn: 247068
* CGDebugInfo: Factor out a getOrCreateStandaloneType() method.Adrian Prantl2015-08-271-0/+3
| | | | | | | | | | | Usually debug info is created on the fly while during codegen. With this API it becomes possible to create standalone debug info for types that are not referenced by any code, such as emitting debug info for a clang module or for implementing something like -gfull. Because on-the-fly debug info generation may still insert retained types on top of them, all RetainedTypes are uniqued in CGDebugInfo::finalize(). llvm-svn: 246210
* Add a -gmodules option to the driver and a -dwarf-ext-refs to cc1Adrian Prantl2015-08-271-0/+1
| | | | | | | | | | | | | to enable the use of external type references in the debug info (a.k.a. module debugging). The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs" and passes that to cc1. All this does at the moment is set a flag codegenopts. http://reviews.llvm.org/D11958 llvm-svn: 246192
* Wdeprecated: ApplyDebugLocation is returned by value yet if it is ever ↵David Blaikie2015-08-121-1/+4
| | | | | | copied (rather than RVO'd) that would be broken, make it movable instead llvm-svn: 244838
* [UB] Another place where we were trying to put string data intoChandler Carruth2015-08-041-2/+4
| | | | | | | | | | | | | a BumpPtrAllocator. This at least now handles the case where there is no concatentation without calling memcpy on a null pointer. It might be interesting to handle the case where everything is empty without round-tripping through the allocator, but it wasn't clear to me if the pointer returned is significant in any way, so I've left it in a conservatively more-correct state. Again, found with UBSan. llvm-svn: 243948
* DI: Update for LLVM API change for local variablesDuncan P. N. Exon Smith2015-07-311-4/+3
| | | | | | | | Adjust to LLVM DIBuilder API changes in r243764, using `createAutoVariable()` and `createParameterVariable()` in place of `createLocalVariable()`. No real functionality change here. llvm-svn: 243765
* DI: Make getOrCreateLimitedType() return DICompositeType, NFCDuncan P. N. Exon Smith2015-07-241-1/+2
| | | | | | | | | Change `getOrCreateLimitedType()` to return a `DICompositeType` and remove the casts from its callers. Inside, I've strengthened a `cast` from `DICompositeTypeBase`, but the casts in the callers already prove that this is safe. There should be no functionality change here. llvm-svn: 243155
* DI: Make StaticDataMemberCache type-safe, NFCDuncan P. N. Exon Smith2015-07-241-1/+2
| | | | | | | Change `StaticDataMemberCache` to store references to `DIDerivedType` directly, and remove now-unnecessary casts from the accessors. llvm-svn: 243129
* Cleanup the doxygen comments in CGDebugInfo.cpp according to the codingAdrian Prantl2015-07-081-7/+54
| | | | | | | standards. Remove several hilariously out-of-date and redundant comments and move the non-redundant ones into the header file. llvm-svn: 241733
* Cleanup the doxygen comments in CGDebugInfo.h according to the codingAdrian Prantl2015-07-081-126/+122
| | | | | | standards and clang-format the file. llvm-svn: 241723
* Fix the spelling of Objective-C.Adrian Prantl2015-07-081-2/+1
| | | | llvm-svn: 241722
* Debug info: Emit distinct __block_literal_generic types for blocks withAdrian Prantl2015-07-071-1/+0
| | | | | | | | | | different function signatures. (Previously clang would emit all block pointer types with the type of the first block pointer in the compile unit.) rdar://problem/21602473 llvm-svn: 241534
* Revert "[DebugInfo] Fix debug info generation for function static variables, ↵David Blaikie2015-07-011-11/+0
| | | | | | | | | | typedefs, and records" Caused PR24008. This reverts commit r241154. llvm-svn: 241177
* [DebugInfo] Fix debug info generation for function static variables, ↵Michael Kuperstein2015-07-011-0/+11
| | | | | | | | | | | | | | | typedefs, and records Function static variables, typedefs and records (class, struct or union) declared inside a lexical scope were associated with the function as their parent scope, rather than the lexical scope they are defined or declared in. This fixes PR19238 Patch by: amjad.aboud@intel.com Differential Revision: http://reviews.llvm.org/D9760 llvm-svn: 241154
* Debug Info: Emit debug info for @import declarations.Adrian Prantl2015-06-301-0/+10
| | | | | | | | | This allows a module-aware debugger such as LLDB to import the currently visible modules before dropping into the expression evaluator. rdar://problem/20965932 llvm-svn: 241084
* DebugInfo: Metadata constructs now start with DI*Duncan P. N. Exon Smith2015-04-291-110/+110
| | | | | | | | | | LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now that the `DIDescriptor` hierarchy has been gone for about a week. This commit was generated using the rename-md-di-nodes.sh upgrade script attached to PR23080, followed by running clang-format-diff.py on the `lib/` portion of the patch. llvm-svn: 236121
* DebugInfo: Prepare for removal of DIArray and DITypeArray typedefsDuncan P. N. Exon Smith2015-04-211-7/+8
| | | | | | | | An upcoming LLVM commit will remove the `DIArray` and `DITypeArray` typedefs that shadow `DebugNodeArray` and `MDTypeRefArray`, respectively. Use those types directly. llvm-svn: 235412
* DebugInfo: Prepare for deletion of DIDescriptor subclassesDuncan P. N. Exon Smith2015-04-211-5/+6
| | | | | | | An upcoming LLVM commit will delete all the remaining subclasses of (the already deleted) `DIDescriptor`. Stop using them. llvm-svn: 235403
* DebugInfo: Prepare for deletion of subclasses of DIScopeDuncan P. N. Exon Smith2015-04-201-49/+48
| | | | | | | | Prepare for the deletion in LLVM of the subclasses of (the already deleted) `DIScope` by using the raw pointers they were wrapping directly. llvm-svn: 235355
* DebugInfo: Prepare for deletion of subclasses of DITypeDuncan P. N. Exon Smith2015-04-201-5/+5
| | | | | | | | | | | Subclasses of (the already deleted) `DIType` will be deleted by an upcoming LLVM commit. Remove references. While `DICompositeType` wraps `MDCompositeTypeBase` and `DIDerivedType` wraps `MDDerivedTypeBase`, most uses of each really meant the more specific `MDCompositeType` and `MDDerivedType`. I updated accordingly. llvm-svn: 235350
* DebugInfo: Prepare for deletion of DITypeDuncan P. N. Exon Smith2015-04-201-68/+70
| | | | | | | `DIType` is going to be deleted by an upcoming LLVM commit, so replace uses with `MDType*`. llvm-svn: 235330
* DebugInfo: Prepare for deletion of DIScopeDuncan P. N. Exon Smith2015-04-201-7/+5
| | | | | | | An upcoming LLVM commit will delete `DIScope`, so update users to `MDScope*`. llvm-svn: 235326
* Remove dead code, NFCDuncan P. N. Exon Smith2015-04-181-3/+0
| | | | llvm-svn: 235246
* DebugInfo: Prepare for deletion of DIDescriptorDuncan P. N. Exon Smith2015-04-181-1/+1
| | | | | | Prepare for upcoming LLVM change to delete `DIDescriptor`. llvm-svn: 235245
* DebugInfo: Update for LLVM API change in DIBuilder (r235111)Duncan P. N. Exon Smith2015-04-161-22/+21
| | | | | | | | | | | | | | | | | LLVM r235111 changed the `DIBuilder` API to stop using `DIDescriptor` and its subclasses. Rolled into this was some tightening up of types: - Scopes: `DIDescriptor` => `MDScope*`. - Generic debug nodes: `DIDescriptor` => `DebugNode*`. - Subroutine types: `DICompositeType` => `MDSubroutineType*`. - Composite types: `DICompositeType` => `MDCompositeType*`. Note that `DIDescriptor` wraps `MDNode`, and `DICompositeType` wraps `MDCompositeTypeBase`. It's this new type strictness that requires changes here. llvm-svn: 235112
* CodeGen: Update for LLVM API change in r228030Duncan P. N. Exon Smith2015-02-031-2/+2
| | | | | | | The mock tags are no longer in `dwarf::LLVMConstants`; they're in `dwarf::Tag`. llvm-svn: 228032
* Address review feedback for r228003.Adrian Prantl2015-02-031-14/+36
| | | | | | | - use named constructors - get rid of MarkAsPrologue llvm-svn: 228021
* Merge ArtificialLocation into ApplyDebugLocation and make a clearAdrian Prantl2015-02-031-21/+19
| | | | | | | | | | | | | | | | distinction between the different use-cases. With the previous default behavior we would occasionally emit empty debug locations in situations where they actually were strictly required (= on invoke insns). We now have a choice between defaulting to an empty location or an artificial location. Specifically, this fixes a bug caused by a missing debug location when emitting C++ EH cleanup blocks from within an artificial function, such as an ObjC destroy helper function. rdar://problem/19670595 llvm-svn: 228003
* Add documentation to ApplyDebugLocation.Adrian Prantl2015-02-031-2/+4
| | | | llvm-svn: 228002
* DebugInfo: Attribute implicit boolean tests to the expression being tested, ↵David Blaikie2015-01-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | not to the outer use of that expression. This is half a fix for a GDB test suite failure that expects to start at 'a' in the following code: void func(int a) if (a && b) ... But instead, without this change, the comparison was assigned to '&&' (well, worse actually - because there was a chained 'a && b && c' and it was assigned to the second '&&' because of a recursive application of this bug) and then the load folded into the comparison so breaking on the function started at '&&' instead of 'a'. The other part of this needs to be fixed in LLVM where it's ignoring the location of the icmp and instead using the location of the branch instruction. The fix to the conditional operator is actually a no-op currently, because the conditional operator's location coincides with 'a' (the start of the conditional expression) but should probably be '?' instead. See the FIXME in the test case that mentions the ARCMigration tool failures when I tried to make that change. llvm-svn: 227356
* Update the doxygen comments in CGDebugInfo.h to follow the coding standards.Adrian Prantl2015-01-271-46/+46
| | | | llvm-svn: 227221
* DebugInfo: Use the preferred location rather than the start location for ↵David Blaikie2015-01-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expression line info This causes things like assignment to refer to the '=' rather than the LHS when attributing the store instruction, for example. There were essentially 3 options for this: * The beginning of an expression (this was the behavior prior to this commit). This meant that stepping through subexpressions would bounce around from subexpressions back to the start of the outer expression, etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be where the actual addition occurred)). * The end of an expression. This seems to be what GCC does /mostly/, and certainly this for function calls. This has the advantage that progress is always 'forwards' (never jumping backwards - except for independent subexpressions if they're evaluated in interesting orders, etc). "x + y + z" would go "x y z" with the additions occurring at y and z after the respective loads. The problem with this is that the user would still have to think fairly hard about precedence to realize which subexpression is being evaluated or which operator overload is being called in, say, an asan backtrace. * The preferred location or 'exprloc'. In this case you get sort of what you'd expect, though it's a bit confusing in its own way due to going 'backwards'. In this case the locations would be: "x y + z +" in lovely postfix arithmetic order. But this does mean that if the op+ were an operator overload, say, and in a backtrace, the backtrace will point to the exact '+' that's being called, not to the end of one of its operands. (actually the operator overload case doesn't work yet for other reasons, but that's being fixed - but this at least gets scalar/complex assignments and other plain operators right) llvm-svn: 227027
* DebugInfo: Remove forced column-info workaround for inlined callsDavid Blaikie2015-01-211-5/+2
| | | | | | | | | | | | | | | | | This workaround was to provide unique call sites to ensure LLVM's inline debug info handling would properly unique two calls to the same function on the same line. Instead, this has now been fixed in LLVM (r226736) and the workaround here can be removed. Originally committed in r176895, but this isn't a straight revert due to all the changes since then. I just searched for anything ForcedColumn* related and removed them. We could test this - but it didn't strike me as terribly valuable once we're no longer adding this workaround everything just works as expected & it's no longer a special case to test for. llvm-svn: 226738
* Recommit r225083 (reverted in r225361) now that calls to aggregate ↵David Blaikie2015-01-181-3/+0
| | | | | | | | | | | | | | | | | | | initializers from in class non-static data members are explicitly attributed to the desired line. The code setting the debug location being removed here was accidentally leaking a location into the call to the non-static data member's ctor call. Without it the call had no location and could cause assertion failures if it was inlined. Now that it has a location (and a correct one at that) this code should hopefully be no longer needed. It's possible of course that other parts of the debug info are also relying on the debug locations being set here to leak to where they're needed - so we might see the same assertions again & will have to investigate what the dependence was/is. But the chances are good that any of those are debug info line table quality bugs we've just not found yet anyway - so it'll be good to flush them out. llvm-svn: 226383
* Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info ↵David Blaikie2015-01-141-28/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | location handling (and follow-up commits). Several pieces of code were relying on implicit debug location setting which usually lead to incorrect line information anyway. So I've fixed those (in r225955 and r225845) separately which should pave the way for this commit to be cleanly reapplied. The reason these implicit dependencies resulted in crashes with this patch is that the debug location would no longer implicitly leak from one place to another, but be set back to invalid. Once a call with no/invalid location was emitted, if that call was ever inlined it could produce invalid debugloc chains and assert during LLVM's codegen. There may be further cases of such bugs in this patch - they're hard to flush out with regression testing, so I'll keep an eye out for reports and investigate/fix them ASAP if they come up. Original commit message: Reapply "DebugInfo: Generalize debug info location handling" Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Recommitted in r224941 and reverted in r224970 after it caused a crash when building compiler-rt. Looks to be due to this change zeroing out the debug location when emitting default arguments (which were meant to inherit their outer expression's location) thus creating call instructions without locations - these create problems for inlining and must not be created. That is fixed and tested in this version of the change. Original commit message: 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: 225956
OpenPOWER on IntegriCloud