maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenObjCXX/debug-info-line.mm

31 lines
531 B
Plaintext
Raw Normal View History

DebugInfo: Correct the location of EH cleanup for blocks This was previously piggybacking on whatever happened to be the last location set on CGDebugInfo/DIBuilder, which was wrong (it was often the current location, such as the 'fn()' call site, not the end of the block). With my improvements to set/unset the location in a scoped manner (r225000) this went from a bad quality situation, to a crash. Fixing this goes part-way to unblocking the recommit of r225000. It's likely that any call to CodeGenFunction::StartFunction without the CurEHLocation set represents a similar bug or risk of a bug. Perhaps there are some callers that know they won't generate EH cleanups, but I'm not sure. I considered a generic catch-fix in StartFunction (just fallback to the GlobalDecl's location) but that seemed like it'd mask bugs where the EH location shouldn't be the same as the decl's location (& indeed by not using that stop-gap I found this bug). We'll see how long I can hold out on the generic catch-all. I might eventually be able to add an assertion in. llvm-svn: 225845
2015-01-14 07:06:27 +08:00
// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -gline-tables-only -fblocks -emit-llvm %s -o - | FileCheck %s
void fn();
struct foo {
~foo();
};
DebugInof: Correct the location of exception cleanups in global ctors/dtors and ObjC methods Without setting the CurEHLocation these cleanups would be attributed to whatever the last active debug line location was (the 'fn' call in the included test cases). By setting CurEHLocation correctly the line information is improved/corrected. This quality bug turned into a crasher with r225000 when, instead of allowing the last location to persist, it would be zero'd out. This could lead to a function call (such as the dtor) being made without a debug location - if that call was subsequently inlined (and the caller and callee had debug info, just not the call instruction) the inliner would violate important constraints about the debug location chains by not updating the inlined instructions to chain up to the callee locations. So, by fixing this bug, I am addressing the assertion failures introduced by r225000 and should be able to recommit that patch with impunity... llvm-svn: 225955
2015-01-14 15:10:46 +08:00
void f1() {
DebugInfo: Correct the location of EH cleanup for blocks This was previously piggybacking on whatever happened to be the last location set on CGDebugInfo/DIBuilder, which was wrong (it was often the current location, such as the 'fn()' call site, not the end of the block). With my improvements to set/unset the location in a scoped manner (r225000) this went from a bad quality situation, to a crash. Fixing this goes part-way to unblocking the recommit of r225000. It's likely that any call to CodeGenFunction::StartFunction without the CurEHLocation set represents a similar bug or risk of a bug. Perhaps there are some callers that know they won't generate EH cleanups, but I'm not sure. I considered a generic catch-fix in StartFunction (just fallback to the GlobalDecl's location) but that seemed like it'd mask bugs where the EH location shouldn't be the same as the decl's location (& indeed by not using that stop-gap I found this bug). We'll see how long I can hold out on the generic catch-all. I might eventually be able to add an assertion in. llvm-svn: 225845
2015-01-14 07:06:27 +08:00
^{
foo f;
fn();
DebugInof: Correct the location of exception cleanups in global ctors/dtors and ObjC methods Without setting the CurEHLocation these cleanups would be attributed to whatever the last active debug line location was (the 'fn' call in the included test cases). By setting CurEHLocation correctly the line information is improved/corrected. This quality bug turned into a crasher with r225000 when, instead of allowing the last location to persist, it would be zero'd out. This could lead to a function call (such as the dtor) being made without a debug location - if that call was subsequently inlined (and the caller and callee had debug info, just not the call instruction) the inliner would violate important constraints about the debug location chains by not updating the inlined instructions to chain up to the callee locations. So, by fixing this bug, I am addressing the assertion failures introduced by r225000 and should be able to recommit that patch with impunity... llvm-svn: 225955
2015-01-14 15:10:46 +08:00
// CHECK: cleanup, !dbg [[DBG_F1:![0-9]*]]
#line 100
DebugInfo: Correct the location of EH cleanup for blocks This was previously piggybacking on whatever happened to be the last location set on CGDebugInfo/DIBuilder, which was wrong (it was often the current location, such as the 'fn()' call site, not the end of the block). With my improvements to set/unset the location in a scoped manner (r225000) this went from a bad quality situation, to a crash. Fixing this goes part-way to unblocking the recommit of r225000. It's likely that any call to CodeGenFunction::StartFunction without the CurEHLocation set represents a similar bug or risk of a bug. Perhaps there are some callers that know they won't generate EH cleanups, but I'm not sure. I considered a generic catch-fix in StartFunction (just fallback to the GlobalDecl's location) but that seemed like it'd mask bugs where the EH location shouldn't be the same as the decl's location (& indeed by not using that stop-gap I found this bug). We'll see how long I can hold out on the generic catch-all. I might eventually be able to add an assertion in. llvm-svn: 225845
2015-01-14 07:06:27 +08:00
}();
}
DebugInof: Correct the location of exception cleanups in global ctors/dtors and ObjC methods Without setting the CurEHLocation these cleanups would be attributed to whatever the last active debug line location was (the 'fn' call in the included test cases). By setting CurEHLocation correctly the line information is improved/corrected. This quality bug turned into a crasher with r225000 when, instead of allowing the last location to persist, it would be zero'd out. This could lead to a function call (such as the dtor) being made without a debug location - if that call was subsequently inlined (and the caller and callee had debug info, just not the call instruction) the inliner would violate important constraints about the debug location chains by not updating the inlined instructions to chain up to the callee locations. So, by fixing this bug, I am addressing the assertion failures introduced by r225000 and should be able to recommit that patch with impunity... llvm-svn: 225955
2015-01-14 15:10:46 +08:00
// CHECK-LABEL: define internal i8* @"\01-[TNSObject init]"
@implementation TNSObject
- (id)init
{
foo f;
fn();
// CHECK: cleanup, !dbg [[DBG_TNSO:![0-9]*]]
#line 200
}
@end
IR: Move MDLocation into place (clang testcases) Update testcases to match LLVM change in r226048. llvm-svn: 226049
2015-01-15 06:28:03 +08:00
// CHECK: [[DBG_F1]] = !MDLocation(line: 100,
// CHECK: [[DBG_TNSO]] = !MDLocation(line: 200,