replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/llvm/test/DebugInfo/member-order.ll

67 lines
3.0 KiB
LLVM
Raw Normal View History

DebugInfo: Fix ordering of members after r191928 In the case (shown in the attached test) where a member function definition was emitted into debug info the following could occur: 1) build the debug info for the member function definition 2) in (1), build the debug info for the member function declaration 3) construct and add the member function declaration DIE 4) add it to its context 5) build its context (the type it is a member of) 6) construct the members and add them to the type 7) except don't add member functions because "getOrCreateSubprogram" adds the function to its parent anyway 8) except we're only partway through building this subprogram declaration so it hasn't been added yet - but we returned the partially constructed DIE (since it's already in the MDNode->DIE mapping to avoid infinitely recursing trying to create the member function DIE) 9) once the type is constructed, add the member function to it 10) now the members are out of order (the member function being defined is listed as the last member, even though it was declared as the first) To avoid this, construct the context of the subprogram DIE before we query to see if it exists. That way we never end up creating it before creating its context and ending up in this situation. Alternatively, the type construction that visits/builds all the members could call something like getOrCreateSubprogram, but that doesn't ever do the "add to context" step. Then the type building code would always be responsible for adding members (and the subprogram "addToContextDIE" would no-op because the context building would have added the subprogram declaration to the type/context DIE already). (the test cases updated were overly-sensitive to offsets or abbreviation numbers. We don't have a nice way to make these tests more robust as yet - multiline FileCheck matches would be required) llvm-svn: 191939
2013-10-04 09:39:59 +08:00
; REQUIRES: object-emission
Reland r200340 - 'Add line table debug info to COFF files when using a win32 triple' This incorporates a couple of fixes reviewed at http://llvm-reviews.chandlerc.com/D2651 llvm-svn: 200440
2014-01-30 09:39:17 +08:00
; RUN: %llc_dwarf -filetype=obj -O0 < %s | llvm-dwarfdump -debug-dump=info - | FileCheck %s
DebugInfo: Fix ordering of members after r191928 In the case (shown in the attached test) where a member function definition was emitted into debug info the following could occur: 1) build the debug info for the member function definition 2) in (1), build the debug info for the member function declaration 3) construct and add the member function declaration DIE 4) add it to its context 5) build its context (the type it is a member of) 6) construct the members and add them to the type 7) except don't add member functions because "getOrCreateSubprogram" adds the function to its parent anyway 8) except we're only partway through building this subprogram declaration so it hasn't been added yet - but we returned the partially constructed DIE (since it's already in the MDNode->DIE mapping to avoid infinitely recursing trying to create the member function DIE) 9) once the type is constructed, add the member function to it 10) now the members are out of order (the member function being defined is listed as the last member, even though it was declared as the first) To avoid this, construct the context of the subprogram DIE before we query to see if it exists. That way we never end up creating it before creating its context and ending up in this situation. Alternatively, the type construction that visits/builds all the members could call something like getOrCreateSubprogram, but that doesn't ever do the "add to context" step. Then the type building code would always be responsible for adding members (and the subprogram "addToContextDIE" would no-op because the context building would have added the subprogram declaration to the type/context DIE already). (the test cases updated were overly-sensitive to offsets or abbreviation numbers. We don't have a nice way to make these tests more robust as yet - multiline FileCheck matches would be required) llvm-svn: 191939
2013-10-04 09:39:59 +08:00
; generated by clang from:
; struct foo {
; void f1();
; void f2();
; };
;
; void foo::f1() {
; }
; CHECK: DW_TAG_structure_type
; CHECK-NEXT: DW_AT_name {{.*}} "foo"
; CHECK-NOT: NULL
; CHECK: DW_TAG_subprogram
; CHECK-NOT: NULL
; CHECK: DW_AT_name {{.*}} "f1"
; CHECK: DW_TAG_subprogram
; CHECK-NOT: NULL
; CHECK: DW_AT_name {{.*}} "f2"
%struct.foo = type { i8 }
; Function Attrs: nounwind uwtable
define void @_ZN3foo2f1Ev(%struct.foo* %this) #0 align 2 {
entry:
%this.addr = alloca %struct.foo*, align 8
store %struct.foo* %this, %struct.foo** %this.addr, align 8
IR: Make metadata typeless in assembly Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. llvm-svn: 224257
2014-12-16 03:07:53 +08:00
call void @llvm.dbg.declare(metadata %struct.foo** %this.addr, metadata !16, metadata !{!"0x102"}), !dbg !18
DebugInfo: Fix ordering of members after r191928 In the case (shown in the attached test) where a member function definition was emitted into debug info the following could occur: 1) build the debug info for the member function definition 2) in (1), build the debug info for the member function declaration 3) construct and add the member function declaration DIE 4) add it to its context 5) build its context (the type it is a member of) 6) construct the members and add them to the type 7) except don't add member functions because "getOrCreateSubprogram" adds the function to its parent anyway 8) except we're only partway through building this subprogram declaration so it hasn't been added yet - but we returned the partially constructed DIE (since it's already in the MDNode->DIE mapping to avoid infinitely recursing trying to create the member function DIE) 9) once the type is constructed, add the member function to it 10) now the members are out of order (the member function being defined is listed as the last member, even though it was declared as the first) To avoid this, construct the context of the subprogram DIE before we query to see if it exists. That way we never end up creating it before creating its context and ending up in this situation. Alternatively, the type construction that visits/builds all the members could call something like getOrCreateSubprogram, but that doesn't ever do the "add to context" step. Then the type building code would always be responsible for adding members (and the subprogram "addToContextDIE" would no-op because the context building would have added the subprogram declaration to the type/context DIE already). (the test cases updated were overly-sensitive to offsets or abbreviation numbers. We don't have a nice way to make these tests more robust as yet - multiline FileCheck matches would be required) llvm-svn: 191939
2013-10-04 09:39:59 +08:00
%this1 = load %struct.foo** %this.addr
ret void, !dbg !19
}
; 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-02 02:55:02 +08:00
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
DebugInfo: Fix ordering of members after r191928 In the case (shown in the attached test) where a member function definition was emitted into debug info the following could occur: 1) build the debug info for the member function definition 2) in (1), build the debug info for the member function declaration 3) construct and add the member function declaration DIE 4) add it to its context 5) build its context (the type it is a member of) 6) construct the members and add them to the type 7) except don't add member functions because "getOrCreateSubprogram" adds the function to its parent anyway 8) except we're only partway through building this subprogram declaration so it hasn't been added yet - but we returned the partially constructed DIE (since it's already in the MDNode->DIE mapping to avoid infinitely recursing trying to create the member function DIE) 9) once the type is constructed, add the member function to it 10) now the members are out of order (the member function being defined is listed as the last member, even though it was declared as the first) To avoid this, construct the context of the subprogram DIE before we query to see if it exists. That way we never end up creating it before creating its context and ending up in this situation. Alternatively, the type construction that visits/builds all the members could call something like getOrCreateSubprogram, but that doesn't ever do the "add to context" step. Then the type building code would always be responsible for adding members (and the subprogram "addToContextDIE" would no-op because the context building would have added the subprogram declaration to the type/context DIE already). (the test cases updated were overly-sensitive to offsets or abbreviation numbers. We don't have a nice way to make these tests more robust as yet - multiline FileCheck matches would be required) llvm-svn: 191939
2013-10-04 09:39:59 +08:00
attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { nounwind readnone }
!llvm.dbg.cu = !{!0}
Debug Info: update testing cases to specify the debug info version number. We are going to drop debug info without a version number or with a different version number, to make sure we don't crash when we see bitcode files with different debug info metadata format. llvm-svn: 195504
2013-11-23 05:49:45 +08:00
!llvm.module.flags = !{!15, !20}
DebugInfo: Fix ordering of members after r191928 In the case (shown in the attached test) where a member function definition was emitted into debug info the following could occur: 1) build the debug info for the member function definition 2) in (1), build the debug info for the member function declaration 3) construct and add the member function declaration DIE 4) add it to its context 5) build its context (the type it is a member of) 6) construct the members and add them to the type 7) except don't add member functions because "getOrCreateSubprogram" adds the function to its parent anyway 8) except we're only partway through building this subprogram declaration so it hasn't been added yet - but we returned the partially constructed DIE (since it's already in the MDNode->DIE mapping to avoid infinitely recursing trying to create the member function DIE) 9) once the type is constructed, add the member function to it 10) now the members are out of order (the member function being defined is listed as the last member, even though it was declared as the first) To avoid this, construct the context of the subprogram DIE before we query to see if it exists. That way we never end up creating it before creating its context and ending up in this situation. Alternatively, the type construction that visits/builds all the members could call something like getOrCreateSubprogram, but that doesn't ever do the "add to context" step. Then the type building code would always be responsible for adding members (and the subprogram "addToContextDIE" would no-op because the context building would have added the subprogram declaration to the type/context DIE already). (the test cases updated were overly-sensitive to offsets or abbreviation numbers. We don't have a nice way to make these tests more robust as yet - multiline FileCheck matches would be required) llvm-svn: 191939
2013-10-04 09:39:59 +08:00
IR: Make metadata typeless in assembly Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. llvm-svn: 224257
2014-12-16 03:07:53 +08:00
!0 = !{!"0x11\004\00clang version 3.4 \000\00\000\00\000", !1, !2, !3, !13, !2, !2} ; [ DW_TAG_compile_unit ] [/tmp/dbginfo/member-order.cpp] [DW_LANG_C_plus_plus]
!1 = !{!"member-order.cpp", !"/tmp/dbginfo"}
!2 = !{}
!3 = !{!4}
!4 = !{!"0x13\00foo\001\008\008\000\000\000", !1, null, null, !5, null, null, !"_ZTS3foo"} ; [ DW_TAG_structure_type ] [foo] [line 1, size 8, align 8, offset 0] [def] [from ]
!5 = !{!6, !11}
!6 = !{!"0x2e\00f1\00f1\00_ZN3foo2f1Ev\002\000\000\000\006\00256\000\002", !1, !4, !7, null, null, null, i32 0, !10} ; [ DW_TAG_subprogram ] [line 2] [f1]
!7 = !{!"0x15\00\000\000\000\000\000\000", i32 0, null, null, !8, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
!8 = !{null, !9}
!9 = !{!"0xf\00\000\0064\0064\000\001088", null, null, !"_ZTS3foo"} ; [ DW_TAG_pointer_type ] [line 0, size 64, align 64, offset 0] [artificial] [from _ZTS3foo]
!10 = !{i32 786468}
!11 = !{!"0x2e\00f2\00f2\00_ZN3foo2f2Ev\003\000\000\000\006\00256\000\003", !1, !4, !7, null, null, null, i32 0, !12} ; [ DW_TAG_subprogram ] [line 3] [f2]
!12 = !{i32 786468}
!13 = !{!14}
!14 = !{!"0x2e\00f1\00f1\00_ZN3foo2f1Ev\006\000\001\000\006\00256\000\006", !1, null, !7, null, void (%struct.foo*)* @_ZN3foo2f1Ev, null, !6, !2} ; [ DW_TAG_subprogram ] [line 6] [def] [f1]
!15 = !{i32 2, !"Dwarf Version", i32 4}
!16 = !{!"0x101\00this\0016777216\001088", !14, null, !17} ; [ DW_TAG_arg_variable ] [this] [line 0]
!17 = !{!"0xf\00\000\0064\0064\000\000", null, null, !"_ZTS3foo"} ; [ DW_TAG_pointer_type ] [line 0, size 64, align 64, offset 0] [from _ZTS3foo]
!18 = !{i32 0, i32 0, !14, null}
!19 = !{i32 7, i32 0, !14, null}
!20 = !{i32 1, !"Debug Info Version", i32 2}