RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-25 22:12:57 +02:00
Code Issues Projects Releases Wiki Activity
dd56e9aa72
llvm-mirror/test/DebugInfo/incorrect-variable-debugloc.ll

392 lines
16 KiB
LLVM
Raw Normal View History

DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
; REQUIRES: object-emission
; RUN: %llc_dwarf -O2 -filetype=obj < %s | llvm-dwarfdump -debug-dump=info - | FileCheck %s
; This is a test case that's as reduced as I can get it, though I haven't fully
; understood the mechanisms by which this bug occurs, so perhaps there's further
; simplification to be had (it's certainly a bit non-obvious what's going on). I
; hesitate to hand-craft or otherwise simplify the IR compared to what Clang
; generates as this is a particular tickling of optimizations and debug location
; propagation I want a realistic example of.
; Generated with clang-tot -cc1 -g -O2 -w -std=c++11 -fsanitize=address,use-after-return -fcxx-exceptions -fexceptions -x c++ incorrect-variable-debug-loc.cpp -emit-llvm
; struct A {
; int m_fn1();
; };
;
; struct B {
; void __attribute__((always_inline)) m_fn2() { i = 0; }
; int i;
; };
;
; struct C {
; void m_fn3();
; int j;
; B b;
; };
;
; int fn1() {
; C A;
; A.b.m_fn2();
; A.m_fn3();
; }
; void C::m_fn3() {
; A().m_fn1();
; b.m_fn2();
; }
; CHECK: DW_TAG_structure_type
; CHECK-NEXT: DW_AT_name {{.*}} "C"
[dwarfdump] Print the name for referenced specification of abstract_origin DIEs. Reviewers: dblaikie, samsonov, echristo, aprantl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5466 llvm-svn: 219099
2014-10-06 05:36:31 +02:00
; CHECK: DW_TAG_subprogram
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
; CHECK-NOT: DW_TAG
; CHECK: DW_AT_name {{.*}} "m_fn3"
[dwarfdump] Print the name for referenced specification of abstract_origin DIEs. Reviewers: dblaikie, samsonov, echristo, aprantl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5466 llvm-svn: 219099
2014-10-06 05:36:31 +02:00
; CHECK: DW_AT_specification {{.*}} "_ZN1C5m_fn3Ev"
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
; CHECK-NOT: DW_TAG
; CHECK: DW_TAG_formal_parameter
; CHECK-NOT: DW_TAG
; CHECK: DW_AT_name {{.*}} "this"
%struct.C = type { i32, %struct.B }
%struct.B = type { i32 }
%struct.A = type { i8 }
@llvm.global_ctors = appending global [1 x { i32, void ()* }] [{ i32, void ()* } { i32 1, void ()* @asan.module_ctor }]
@__asan_option_detect_stack_use_after_return = external global i32
@__asan_gen_ = private unnamed_addr constant [11 x i8] c"1 32 8 1 A\00", align 1
@__asan_gen_1 = private unnamed_addr constant [13 x i8] c"1 32 1 3 tmp\00", align 1
; Function Attrs: noreturn sanitize_address
define i32 @_Z3fn1v() #0 {
entry:
%MyAlloca = alloca [64 x i8], align 32, !dbg !39
%0 = ptrtoint [64 x i8]* %MyAlloca to i64, !dbg !39
%1 = load i32* @__asan_option_detect_stack_use_after_return, !dbg !39
%2 = icmp ne i32 %1, 0, !dbg !39
br i1 %2, label %3, label %5
; <label>:3 ; preds = %entry
%4 = call i64 @__asan_stack_malloc_0(i64 64, i64 %0), !dbg !39
br label %5
; <label>:5 ; preds = %entry, %3
%6 = phi i64 [ %0, %entry ], [ %4, %3 ], !dbg !39
%7 = add i64 %6, 32, !dbg !39
%8 = inttoptr i64 %7 to %struct.C*, !dbg !39
%9 = inttoptr i64 %6 to i64*, !dbg !39
store i64 1102416563, i64* %9, !dbg !39
%10 = add i64 %6, 8, !dbg !39
%11 = inttoptr i64 %10 to i64*, !dbg !39
store i64 ptrtoint ([11 x i8]* @__asan_gen_ to i64), i64* %11, !dbg !39
%12 = add i64 %6, 16, !dbg !39
%13 = inttoptr i64 %12 to i64*, !dbg !39
store i64 ptrtoint (i32 ()* @_Z3fn1v to i64), i64* %13, !dbg !39
%14 = lshr i64 %6, 3, !dbg !39
%15 = add i64 %14, 2147450880, !dbg !39
%16 = add i64 %15, 0, !dbg !39
%17 = inttoptr i64 %16 to i64*, !dbg !39
store i64 -868083117767659023, i64* %17, !dbg !39
%i.i = getelementptr inbounds %struct.C* %8, i64 0, i32 1, i32 0, !dbg !39
%18 = ptrtoint i32* %i.i to i64, !dbg !39
%19 = lshr i64 %18, 3, !dbg !39
%20 = add i64 %19, 2147450880, !dbg !39
%21 = inttoptr i64 %20 to i8*, !dbg !39
%22 = load i8* %21, !dbg !39
%23 = icmp ne i8 %22, 0, !dbg !39
br i1 %23, label %24, label %30, !dbg !39
; <label>:24 ; preds = %5
%25 = and i64 %18, 7, !dbg !39
%26 = add i64 %25, 3, !dbg !39
%27 = trunc i64 %26 to i8, !dbg !39
%28 = icmp sge i8 %27, %22, !dbg !39
br i1 %28, label %29, label %30
; <label>:29 ; preds = %24
call void @__asan_report_store4(i64 %18), !dbg !39
call void asm sideeffect "", ""()
unreachable
; <label>:30 ; preds = %24, %5
store i32 0, i32* %i.i, align 4, !dbg !39, !tbaa !41
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
tail call void @llvm.dbg.value(metadata !{%struct.C* %8}, i64 0, metadata !27, metadata !{metadata !"0x102"}), !dbg !46
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
call void @_ZN1C5m_fn3Ev(%struct.C* %8), !dbg !47
unreachable, !dbg !47
}
; Function Attrs: sanitize_address
define void @_ZN1C5m_fn3Ev(%struct.C* nocapture %this) #1 align 2 {
entry:
%MyAlloca = alloca [64 x i8], align 32, !dbg !48
%0 = ptrtoint [64 x i8]* %MyAlloca to i64, !dbg !48
%1 = load i32* @__asan_option_detect_stack_use_after_return, !dbg !48
%2 = icmp ne i32 %1, 0, !dbg !48
br i1 %2, label %3, label %5
; <label>:3 ; preds = %entry
%4 = call i64 @__asan_stack_malloc_0(i64 64, i64 %0), !dbg !48
br label %5
; <label>:5 ; preds = %entry, %3
%6 = phi i64 [ %0, %entry ], [ %4, %3 ], !dbg !48
%7 = add i64 %6, 32, !dbg !48
%8 = inttoptr i64 %7 to %struct.A*, !dbg !48
%9 = inttoptr i64 %6 to i64*, !dbg !48
store i64 1102416563, i64* %9, !dbg !48
%10 = add i64 %6, 8, !dbg !48
%11 = inttoptr i64 %10 to i64*, !dbg !48
store i64 ptrtoint ([13 x i8]* @__asan_gen_1 to i64), i64* %11, !dbg !48
%12 = add i64 %6, 16, !dbg !48
%13 = inttoptr i64 %12 to i64*, !dbg !48
store i64 ptrtoint (void (%struct.C*)* @_ZN1C5m_fn3Ev to i64), i64* %13, !dbg !48
%14 = lshr i64 %6, 3, !dbg !48
%15 = add i64 %14, 2147450880, !dbg !48
%16 = add i64 %15, 0, !dbg !48
%17 = inttoptr i64 %16 to i64*, !dbg !48
store i64 -868083113472691727, i64* %17, !dbg !48
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
tail call void @llvm.dbg.value(metadata !{%struct.C* %this}, i64 0, metadata !30, metadata !{metadata !"0x102"}), !dbg !48
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
%call = call i32 @_ZN1A5m_fn1Ev(%struct.A* %8), !dbg !49
%i.i = getelementptr inbounds %struct.C* %this, i64 0, i32 1, i32 0, !dbg !50
%18 = ptrtoint i32* %i.i to i64, !dbg !50
%19 = lshr i64 %18, 3, !dbg !50
%20 = add i64 %19, 2147450880, !dbg !50
%21 = inttoptr i64 %20 to i8*, !dbg !50
%22 = load i8* %21, !dbg !50
%23 = icmp ne i8 %22, 0, !dbg !50
br i1 %23, label %24, label %30, !dbg !50
; <label>:24 ; preds = %5
%25 = and i64 %18, 7, !dbg !50
%26 = add i64 %25, 3, !dbg !50
%27 = trunc i64 %26 to i8, !dbg !50
%28 = icmp sge i8 %27, %22, !dbg !50
br i1 %28, label %29, label %30
; <label>:29 ; preds = %24
call void @__asan_report_store4(i64 %18), !dbg !50
call void asm sideeffect "", ""()
unreachable
; <label>:30 ; preds = %24, %5
store i32 0, i32* %i.i, align 4, !dbg !50, !tbaa !41
store i64 1172321806, i64* %9, !dbg !52
%31 = icmp ne i64 %6, %0, !dbg !52
br i1 %31, label %32, label %39, !dbg !52
; <label>:32 ; preds = %30
%33 = add i64 %15, 0, !dbg !52
%34 = inttoptr i64 %33 to i64*, !dbg !52
store i64 -723401728380766731, i64* %34, !dbg !52
%35 = add i64 %6, 56, !dbg !52
%36 = inttoptr i64 %35 to i64*, !dbg !52
%37 = load i64* %36, !dbg !52
%38 = inttoptr i64 %37 to i8*, !dbg !52
store i8 0, i8* %38, !dbg !52
br label %42, !dbg !52
; <label>:39 ; preds = %30
%40 = add i64 %15, 0, !dbg !52
%41 = inttoptr i64 %40 to i64*, !dbg !52
store i64 0, i64* %41, !dbg !52
br label %42, !dbg !52
; <label>:42 ; preds = %39, %32
ret void, !dbg !52
}
declare i32 @_ZN1A5m_fn1Ev(%struct.A*) #2
; Function Attrs: nounwind readnone
Move the complex address expression out of DIVariable and into an extra argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! Note: I accidentally committed a bogus older version of this patch previously. llvm-svn: 218787
2014-10-01 20:55:02 +02:00
declare void @llvm.dbg.value(metadata, i64, metadata, metadata) #3
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
define internal void @asan.module_ctor() {
tail call void @__asan_init_v3()
ret void
}
declare void @__asan_init_v3()
declare void @__asan_report_load1(i64)
declare void @__asan_load1(i64)
declare void @__asan_report_load2(i64)
declare void @__asan_load2(i64)
declare void @__asan_report_load4(i64)
declare void @__asan_load4(i64)
declare void @__asan_report_load8(i64)
declare void @__asan_load8(i64)
declare void @__asan_report_load16(i64)
declare void @__asan_load16(i64)
declare void @__asan_report_store1(i64)
declare void @__asan_store1(i64)
declare void @__asan_report_store2(i64)
declare void @__asan_store2(i64)
declare void @__asan_report_store4(i64)
declare void @__asan_store4(i64)
declare void @__asan_report_store8(i64)
declare void @__asan_store8(i64)
declare void @__asan_report_store16(i64)
declare void @__asan_store16(i64)
declare void @__asan_report_load_n(i64, i64)
declare void @__asan_report_store_n(i64, i64)
declare void @__asan_loadN(i64, i64)
declare void @__asan_storeN(i64, i64)
declare i8* @__asan_memmove(i8*, i8*, i64)
declare i8* @__asan_memcpy(i8*, i8*, i64)
declare i8* @__asan_memset(i8*, i32, i64)
declare void @__asan_handle_no_return()
declare void @__sanitizer_cov()
declare void @__sanitizer_ptr_cmp(i64, i64)
declare void @__sanitizer_ptr_sub(i64, i64)
declare i64 @__asan_stack_malloc_0(i64, i64)
declare void @__asan_stack_free_0(i64, i64, i64)
declare i64 @__asan_stack_malloc_1(i64, i64)
declare void @__asan_stack_free_1(i64, i64, i64)
declare i64 @__asan_stack_malloc_2(i64, i64)
declare void @__asan_stack_free_2(i64, i64, i64)
declare i64 @__asan_stack_malloc_3(i64, i64)
declare void @__asan_stack_free_3(i64, i64, i64)
declare i64 @__asan_stack_malloc_4(i64, i64)
declare void @__asan_stack_free_4(i64, i64, i64)
declare i64 @__asan_stack_malloc_5(i64, i64)
declare void @__asan_stack_free_5(i64, i64, i64)
declare i64 @__asan_stack_malloc_6(i64, i64)
declare void @__asan_stack_free_6(i64, i64, i64)
declare i64 @__asan_stack_malloc_7(i64, i64)
declare void @__asan_stack_free_7(i64, i64, i64)
declare i64 @__asan_stack_malloc_8(i64, i64)
declare void @__asan_stack_free_8(i64, i64, i64)
declare i64 @__asan_stack_malloc_9(i64, i64)
declare void @__asan_stack_free_9(i64, i64, i64)
declare i64 @__asan_stack_malloc_10(i64, i64)
declare void @__asan_stack_free_10(i64, i64, i64)
declare void @__asan_poison_stack_memory(i64, i64)
declare void @__asan_unpoison_stack_memory(i64, i64)
declare void @__asan_before_dynamic_init(i64)
declare void @__asan_after_dynamic_init()
declare void @__asan_register_globals(i64, i64)
declare void @__asan_unregister_globals(i64, i64)
declare void @__sanitizer_cov_module_init(i64)
attributes #0 = { noreturn sanitize_address "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "no-realign-stack" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { sanitize_address "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "no-realign-stack" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #2 = { "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "no-realign-stack" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #3 = { nounwind readnone }
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!36, !37}
!llvm.ident = !{!38}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!0 = metadata !{metadata !"0x11\004\00clang version 3.5.0 \001\00\000\00\001", metadata !1, metadata !2, metadata !3, metadata !21, metadata !2, metadata !2} ; [ DW_TAG_compile_unit ] [/tmp/dbginfo/<stdin>] [DW_LANG_C_plus_plus]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!1 = metadata !{metadata !"<stdin>", metadata !"/tmp/dbginfo"}
!2 = metadata !{}
!3 = metadata !{metadata !4, metadata !14}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!4 = metadata !{metadata !"0x13\00C\0010\0064\0032\000\000\000", metadata !5, null, null, metadata !6, null, null, metadata !"_ZTS1C"} ; [ DW_TAG_structure_type ] [C] [line 10, size 64, align 32, offset 0] [def] [from ]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!5 = metadata !{metadata !"incorrect-variable-debug-loc.cpp", metadata !"/tmp/dbginfo"}
!6 = metadata !{metadata !7, metadata !9, metadata !10}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!7 = metadata !{metadata !"0xd\00j\0012\0032\0032\000\000", metadata !5, metadata !"_ZTS1C", metadata !8} ; [ DW_TAG_member ] [j] [line 12, size 32, align 32, offset 0] [from int]
!8 = metadata !{metadata !"0x24\00int\000\0032\0032\000\000\005", null, null} ; [ DW_TAG_base_type ] [int] [line 0, size 32, align 32, offset 0, enc DW_ATE_signed]
!9 = metadata !{metadata !"0xd\00b\0013\0032\0032\0032\000", metadata !5, metadata !"_ZTS1C", metadata !"_ZTS1B"} ; [ DW_TAG_member ] [b] [line 13, size 32, align 32, offset 32] [from _ZTS1B]
!10 = metadata !{metadata !"0x2e\00m_fn3\00m_fn3\00_ZN1C5m_fn3Ev\0011\000\000\000\006\00256\001\0011", metadata !5, metadata !"_ZTS1C", metadata !11, null, null, null, i32 0, null} ; [ DW_TAG_subprogram ] [line 11] [m_fn3]
!11 = metadata !{metadata !"0x15\00\000\000\000\000\000\000", i32 0, null, null, metadata !12, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!12 = metadata !{null, metadata !13}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!13 = metadata !{metadata !"0xf\00\000\0064\0064\000\001088", null, null, metadata !"_ZTS1C"} ; [ DW_TAG_pointer_type ] [line 0, size 64, align 64, offset 0] [artificial] [from _ZTS1C]
!14 = metadata !{metadata !"0x13\00B\005\0032\0032\000\000\000", metadata !5, null, null, metadata !15, null, null, metadata !"_ZTS1B"} ; [ DW_TAG_structure_type ] [B] [line 5, size 32, align 32, offset 0] [def] [from ]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!15 = metadata !{metadata !16, metadata !17}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!16 = metadata !{metadata !"0xd\00i\007\0032\0032\000\000", metadata !5, metadata !"_ZTS1B", metadata !8} ; [ DW_TAG_member ] [i] [line 7, size 32, align 32, offset 0] [from int]
!17 = metadata !{metadata !"0x2e\00m_fn2\00m_fn2\00_ZN1B5m_fn2Ev\006\000\000\000\006\00256\001\006", metadata !5, metadata !"_ZTS1B", metadata !18, null, null, null, i32 0, null} ; [ DW_TAG_subprogram ] [line 6] [m_fn2]
!18 = metadata !{metadata !"0x15\00\000\000\000\000\000\000", i32 0, null, null, metadata !19, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!19 = metadata !{null, metadata !20}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!20 = metadata !{metadata !"0xf\00\000\0064\0064\000\001088", null, null, metadata !"_ZTS1B"} ; [ DW_TAG_pointer_type ] [line 0, size 64, align 64, offset 0] [artificial] [from _ZTS1B]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!21 = metadata !{metadata !22, metadata !28, metadata !32}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!22 = metadata !{metadata !"0x2e\00fn1\00fn1\00_Z3fn1v\0016\000\001\000\006\00256\001\0016", metadata !5, metadata !23, metadata !24, null, i32 ()* @_Z3fn1v, null, null, metadata !26} ; [ DW_TAG_subprogram ] [line 16] [def] [fn1]
!23 = metadata !{metadata !"0x29", metadata !5} ; [ DW_TAG_file_type ] [/tmp/dbginfo/incorrect-variable-debug-loc.cpp]
!24 = metadata !{metadata !"0x15\00\000\000\000\000\000\000", i32 0, null, null, metadata !25, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!25 = metadata !{metadata !8}
!26 = metadata !{metadata !27}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!27 = metadata !{metadata !"0x100\00A\0017\000", metadata !22, metadata !23, metadata !"_ZTS1C"} ; [ DW_TAG_auto_variable ] [A] [line 17]
!28 = metadata !{metadata !"0x2e\00m_fn3\00m_fn3\00_ZN1C5m_fn3Ev\0021\000\001\000\006\00256\001\0021", metadata !5, metadata !"_ZTS1C", metadata !11, null, void (%struct.C*)* @_ZN1C5m_fn3Ev, null, metadata !10, metadata !29} ; [ DW_TAG_subprogram ] [line 21] [def] [m_fn3]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!29 = metadata !{metadata !30}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!30 = metadata !{metadata !"0x101\00this\0016777216\001088", metadata !28, null, metadata !31} ; [ DW_TAG_arg_variable ] [this] [line 0]
!31 = metadata !{metadata !"0xf\00\000\0064\0064\000\000", null, null, metadata !"_ZTS1C"} ; [ DW_TAG_pointer_type ] [line 0, size 64, align 64, offset 0] [from _ZTS1C]
!32 = metadata !{metadata !"0x2e\00m_fn2\00m_fn2\00_ZN1B5m_fn2Ev\006\000\001\000\006\00256\001\006", metadata !5, metadata !"_ZTS1B", metadata !18, null, null, null, metadata !17, metadata !33} ; [ DW_TAG_subprogram ] [line 6] [def] [m_fn2]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!33 = metadata !{metadata !34}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!34 = metadata !{metadata !"0x101\00this\0016777216\001088", metadata !32, null, metadata !35} ; [ DW_TAG_arg_variable ] [this] [line 0]
!35 = metadata !{metadata !"0xf\00\000\0064\0064\000\000", null, null, metadata !"_ZTS1B"} ; [ DW_TAG_pointer_type ] [line 0, size 64, align 64, offset 0] [from _ZTS1B]
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!36 = metadata !{i32 2, metadata !"Dwarf Version", i32 4}
Revert "Revert "DI: Fold constant arguments into a single MDString"" This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-03 22:01:09 +02:00
!37 = metadata !{i32 2, metadata !"Debug Info Version", i32 2}
DebugInfo: Assert that DbgVariables have associated DIEs This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
2014-06-01 05:38:13 +02:00
!38 = metadata !{metadata !"clang version 3.5.0 "}
!39 = metadata !{i32 6, i32 0, metadata !32, metadata !40}
!40 = metadata !{i32 18, i32 0, metadata !22, null}
!41 = metadata !{metadata !42, metadata !43, i64 0}
!42 = metadata !{metadata !"_ZTS1B", metadata !43, i64 0}
!43 = metadata !{metadata !"int", metadata !44, i64 0}
!44 = metadata !{metadata !"omnipotent char", metadata !45, i64 0}
!45 = metadata !{metadata !"Simple C/C++ TBAA"}
!46 = metadata !{i32 17, i32 0, metadata !22, null}
!47 = metadata !{i32 19, i32 0, metadata !22, null}
!48 = metadata !{i32 0, i32 0, metadata !28, null}
!49 = metadata !{i32 22, i32 0, metadata !28, null}
!50 = metadata !{i32 6, i32 0, metadata !32, metadata !51}
!51 = metadata !{i32 23, i32 0, metadata !28, null}
!52 = metadata !{i32 24, i32 0, metadata !28, null}
Reference in New Issue Copy Permalink