summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGDebugInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Debug Info: Emit debug info for @import declarations.Adrian Prantl2015-06-301-0/+54
| | | | | | | | | 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
* Omit 'nodebug' methods from the class description.Paul Robinson2015-06-251-1/+2
| | | | llvm-svn: 240664
* [CodeGen] Rename EmitMemberPointer to EmitMemberFunctionPointerDavid Majnemer2015-06-231-1/+1
| | | | llvm-svn: 240382
* Debug Info: Turn on ODR type uniquing for (the C++ part of) Objective-C++.Adrian Prantl2015-06-151-4/+15
| | | | | | rdar://problem/20571359 llvm-svn: 239781
* [MS ABI, DebugInfo] Omit the size for model-less pointers-to-membersDavid Majnemer2015-05-261-3/+5
| | | | | | | | | | | | | | The representation of a pointer-to-member in the MS ABI is governed by the layout of the relevant class or if a model has been explicitly specified. If no model is specified, then an appropriate "worst-case-scenario" model is implicitly chosen if, and only, if the pointer-to-member type's representation was needed. Debug info cannot force a pointer-to-member type to have a representation so do not try to query the size of such a type unless we know it is safe to do so. llvm-svn: 238259
* Debug info: Adapt to new DIBuilder interface.Adrian Prantl2015-05-211-0/+1
| | | | llvm-svn: 237948
* Debug Info: Represent local anonymous unions as anonymous unionsAdrian Prantl2015-04-291-2/+9
| | | | | | | | | | | | | | | | and as artificial local variables in the debug info. This is a follow-up to r236059. We can't get rid of the local variables entirely because the gdb buildbot depends on them, but we can mark them as artificial while still emitting the correct debug info. As I learned from review comments other compilers also follow this model. A paired commit in LLVM temporarily relaxes the debug info verifier to not check the integrity of DW_OP_bit_pieces of artificial variables. rdar://problem/20730771 llvm-svn: 236125
* DebugInfo: Metadata constructs now start with DI*Duncan P. N. Exon Smith2015-04-291-290/+289
| | | | | | | | | | 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
* Revert "Debug Info: Represent local anonymous unions as anonymous unions"Adrian Prantl2015-04-291-0/+25
| | | | | | This reverts commit r236059 as it breaks the gdb buildbot. llvm-svn: 236110
* Debug Info: Represent local anonymous unions as anonymous unionsAdrian Prantl2015-04-281-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the debug info. This patch deletes a hack that emits the members of local anonymous unions as local variables. Besides being morally wrong, the existing representation using local variables breaks internal assumptions about the local variables' storage size. Compiling ``` void fn1() { union { int i; char c; }; i = c; } ``` with -g -O3 -verify will cause the verifier to fail after SROA splits the 32-bit storage for the "local variable" c into two pieces because the second piece is clearly outside the 8-bit range that is expected for a variable of type char. Given the choice I'd rather fix the debug representation than weaken the verifier. Debuggers generally already know how to deal with anonymous unions when they are members of C++ record types, but they may have problems finding the local anonymous struct members in the expression evaluator. rdar://problem/20730771 llvm-svn: 236059
* Replace getPointeeType()->isFunctionType with isMemberDataPointerTypeDavid Majnemer2015-04-241-1/+1
| | | | llvm-svn: 235682
* DebugInfo: Prepare for removal of DIArray and DITypeArray typedefsDuncan P. N. Exon Smith2015-04-211-31/+36
| | | | | | | | 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-54/+41
| | | | | | | 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-79/+80
| | | | | | | | 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-16/+14
| | | | | | | | | | | 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-174/+159
| | | | | | | `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/+7
| | | | | | | An upcoming LLVM commit will delete `DIScope`, so update users to `MDScope*`. llvm-svn: 235326
* DebugInfo: Prepare for deletion of DIDescriptorDuncan P. N. Exon Smith2015-04-181-22/+13
| | | | | | 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-91/+75
| | | | | | | | | | | | | | | | | 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
* DebugInfo: Prepare for DIDescriptor to be gutted in LLVMDuncan P. N. Exon Smith2015-04-161-28/+28
| | | | | | | All the API is about to be dropped from `DIDescriptor` in LLVM, so stop using it. llvm-svn: 235068
* DebugInfo: Prepare for DIScope to be gutted in LLVMDuncan P. N. Exon Smith2015-04-161-2/+2
| | | | | | | An upcoming LLVM commit will gut `DIScope`, so just use `MDScope*` directly. llvm-svn: 235066
* DebugInfo: Prepare for DIType to be guttedDuncan P. N. Exon Smith2015-04-161-17/+14
| | | | | | | `DIType` and its subclasses are about to be gutted in LLVM. Prepare for that by treating these like the raw pointers they wrap. llvm-svn: 235063
* DebugInfo: Prepare for LLVM change removing DIType::isValid()Duncan P. N. Exon Smith2015-04-151-3/+3
| | | | | | This is being replaced with a null check. llvm-svn: 235058
* DebugInfo: Prepare for LLVM gutting DICompileUnit/DIFileDuncan P. N. Exon Smith2015-04-151-9/+10
| | | | | | | An upcoming LLVM commit will gut `DICompileUnit` and `DIFile`, so start treating them more like pointers. llvm-svn: 235054
* DebugInfo: Pass DebugLocs when creating intrinsicsDuncan P. N. Exon Smith2015-04-151-24/+21
| | | | | | | Update for LLVM API change r235041 that makes `DIBuilder` require a `DebugLoc` to create a debug info intrinsic. llvm-svn: 235042
* DebugInfo: Prepare for DISubprogram/DILexicalBlock* to be guttedDuncan P. N. Exon Smith2015-04-141-9/+8
| | | | | | | An upcoming LLVM commit will remove this API, so stop using it. Just access the raw pointers using `operator->()`. llvm-svn: 234848
* DebugInfo: Switch from replaceAllUsesWith() to replaceTemporary()Duncan P. N. Exon Smith2015-04-111-8/+8
| | | | | | | | Stop using `DIDescriptor`'s wrapper around `MDNode::replaceAllUsesWith()` (which is going away). The new home for this logic is `DIBuilder::replaceTemporary()`, added in LLVM r234695. llvm-svn: 234696
* Revert "Fix a compiler error under MSVC"Duncan P. N. Exon Smith2015-04-071-1/+1
| | | | | | | This reverts the bandaid commit in r234308 now that I have a proper fix in LLVM as of r234326. llvm-svn: 234339
* DebugInfo: LLVM API change in r234326 for array-like tuple wrappersDuncan P. N. Exon Smith2015-04-071-9/+7
| | | | | | | | | Update a few calls to `DIBuilder` now that `MDTuple` array-wrappers don't have implicit conversions to `MDTuple*`. I may circle back and update `DIBuilder` to take arrays here, to make it easier for the callers. llvm-svn: 234327
* Fix a compiler error under MSVCTimur Iskhodzhanov2015-04-071-1/+1
| | | | | | | | | Error message was: CGDebugInfo.cpp(1047) : error C2666: 'llvm::MDTypeRefArray::operator []' : 2 overloads have similar conversions DebugInfoMetadata.h(106): could be 'llvm::MDTypeRef llvm::MDTypeRefArray::operator [](unsigned int) const' while trying to match the argument list '(llvm::DITypeArray, int)' llvm-svn: 234308
* DebugInfo: Update for LLVM change in r234290Duncan P. N. Exon Smith2015-04-071-4/+4
| | | | | | The API for `DIArray` changed; use the new one. llvm-svn: 234291
* CGDebugInfo: Stop using DIDescriptor::is*() and auto-castingDuncan P. N. Exon Smith2015-04-061-41/+45
| | | | | | | The clang edition of r234255: use built-in `isa<>`, `dyn_cast<>`, etc., and only build `DIDescriptor`s from pointers that are correctly typed. llvm-svn: 234256
* DebugInfo: Use DILexicalBlockFile::getContext() over getScope()Duncan P. N. Exon Smith2015-04-061-1/+1
| | | | | | | | `getScope()` passes the scope back through a `DILexicalBlock` even though the underlying pointer may be an incompatible `MDSubprogram`. Just use `getContext()` directly. llvm-svn: 234245
* DebugInfo: Use new LLVM API for DebugLocDuncan P. N. Exon Smith2015-03-301-1/+1
| | | | | | | Use the new API for `DebugLoc` added in r233573 before the old one disappears. llvm-svn: 233589
* DebugInfo: Don't call DIBuilder::retainType(nullptr)Duncan P. N. Exon Smith2015-03-271-3/+4
| | | | | | | | | | An upcoming LLVM commit will make calling `DIBuilder::retainType(nullptr)` illegal (actually, it already was, but it wasn't verified). Check for null before calling. This triggered in test/CodeGenObjC/debug-info-block-helper.m. llvm-svn: 233443
* DebugInfo: Check for null before using DITypeDuncan P. N. Exon Smith2015-03-201-1/+1
| | | | | | | | A WIP patch to turn on stricter `DIDescriptor` accessor checks fires here; it's obvious from the code that `T` can be null, so add an explicit check. Caught by dozens of current testcases. llvm-svn: 232791
* DebugInfo: Give externally defined types a size and alignment wherePeter Collingbourne2015-03-011-1/+9
| | | | | | possible. Fixes PR22736. llvm-svn: 230914
* DebugInfo: hoist definition into global context when neededSaleem Abdulrasool2015-02-281-3/+12
| | | | | | | | | | | | When generating debug info for a static inline member which is initialized for the DLLExport storage class, hoist the definition into a non-composite type context. Otherwise, we would trigger an assertion when generating the DIE for the associated global value as the debug context has a type association. This addresses PR22669. Thanks to David Blakie for help in coming up with a solution to this! llvm-svn: 230816
* CGDebugInfo: Use DIImportedEntity default constructor, NFCDuncan P. N. Exon Smith2015-02-261-2/+2
| | | | | | | | | | | | | | | | Use the newly minted `DIImportedEntity` default constructor (r230609) rather than explicitly specifying `nullptr`. The latter will become ambiguous when the new debug info hierarchy is committed, since we'll have both of the following: explicit DIImportedEntity(const MDNode *); DIImportedEntity(const MDImportedEntity *); (Currently we just have the former.) A default constructor is just as clear. llvm-svn: 230610
* Fix PR19351. While building up a composite type it is important to useAdrian Prantl2015-02-111-28/+29
| | | | | | | | | | | a non-uniqueable temporary node that is only turned into a permanent unique or distinct node after it is finished. Otherwise an intermediate node may get accidentally uniqued with another node as illustrated by the testcase. Paired commit with LLVM. llvm-svn: 228855
* CodeGen: Move DebugLocs.Benjamin Kramer2015-02-071-2/+2
| | | | | | | | It's slightly cheaper than copying it, if the DebugLoc points to replaceable metadata every copy is recorded in a DenseMap, moving reduces the peak size of that map. llvm-svn: 228492
* DebugInfo: Attribute cleanup code to the end of the scope, not the end of ↵David Blaikie2015-02-041-1/+0
| | | | | | | | | | | | | | | | | | the function. Now if you break on a dtor and go 'up' in your debugger (or you get an asan failure in a dtor) during an exception unwind, you'll have more context. Instead of all dtors appearing to be called from the '}' of the function, they'll be attributed to the end of the scope of the variable, the same as the non-exceptional dtor call. This doesn't /quite/ remove all uses of CurEHLocation (which might be nice to remove, for a few reasons) - it's still used to choose the location for some other work in the landing pad. It'd be nice to attribute that code to the same location as the exception calls within the block and to remove CurEHLocation. llvm-svn: 228181
* CodeGen: Update for LLVM API change in r228030Duncan P. N. Exon Smith2015-02-031-1/+1
| | | | | | | 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-4/+4
| | | | | | | - use named constructors - get rid of MarkAsPrologue llvm-svn: 228021
* Merge ArtificialLocation into ApplyDebugLocation and make a clearAdrian Prantl2015-02-031-13/+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
* DebugInfo: Use the preferred location rather than the start location for ↵David Blaikie2015-01-251-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+4
| | | | | | | | | | | | | | | | | 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
* Migrate all uses of DIVariable's FlagIndirectVariable to use a DIExpressionAdrian Prantl2015-01-191-11/+12
| | | | | | with a DW_OP_deref instead. llvm-svn: 226474
* Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info ↵David Blaikie2015-01-141-52/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "DebugInfo: Generalize debug info location handling" and related commitsDavid Blaikie2015-01-091-31/+52
| | | | | | | | | | | | This reverts commit r225000, r225021, r225083, r225086, r225090. The root change (r225000) still has several issues where it's caused calls to be emitted without debug locations. This causes assertion failures if/when those calls are inlined. I'll work up some test cases and fixes before recommitting this. llvm-svn: 225555
OpenPOWER on IntegriCloud