maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/DebugInfo/X86/split-global.ll

60 lines
3.3 KiB
LLVM
Raw Normal View History

[IR] Remove the DIExpression field from DIGlobalVariable. This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
2016-12-20 10:09:43 +08:00
; RUN: llc -mtriple=x86_64-apple-darwin %s -o - -filetype=obj | \
; RUN: llvm-dwarfdump --debug-dump=info - | FileCheck %s
;
; Test emitting debug info for fragmented global values.
; This is a handcrafted example of an SROAed global variable.
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.12.0"
%struct.anon = type { i32, i32 }
; CHECK: DW_TAG_variable
; CHECK-NEXT: DW_AT_name {{.*}}"point"
; CHECK-NOT: DW_TAG
[dwarfdump] Pretty print location expressions and location lists Summary: Based on Fred's patch here: https://reviews.llvm.org/D6771 I can't seem to commandeer the old review, so I'm creating a new one. With that change the locations exrpessions are pretty printed inline in the DIE tree. The output looks like this for debug_loc entries: DW_AT_location [DW_FORM_data4] (0x00000000 0x0000000000000001 - 0x000000000000000b: DW_OP_consts +3 0x000000000000000b - 0x0000000000000012: DW_OP_consts +7 0x0000000000000012 - 0x000000000000001b: DW_OP_reg0 RAX, DW_OP_piece 0x4 0x000000000000001b - 0x0000000000000024: DW_OP_breg5 RDI+0) And like this for debug_loc.dwo entries: DW_AT_location [DW_FORM_sec_offset] (0x00000000 Addr idx 2 (w/ length 190): DW_OP_consts +0, DW_OP_stack_value Addr idx 3 (w/ length 23): DW_OP_reg0 RAX, DW_OP_piece 0x4) Simple locations without ranges are printed inline: DW_AT_location [DW_FORM_block1] (DW_OP_reg4 RSI, DW_OP_piece 0x4, DW_OP_bit_piece 0x20 0x0) The debug_loc(.dwo) dumping in changed accordingly to factor the code. Reviewers: dblaikie, aprantl, friss Subscribers: mgorny, javed.absar, hiraditya, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D37123 llvm-svn: 312042
2017-08-30 05:41:21 +08:00
; CHECK: DW_AT_location [DW_FORM_exprloc] (DW_OP_addr 0x4, DW_OP_piece 0x4, DW_OP_addr 0x0, DW_OP_piece 0x4)
[IR] Remove the DIExpression field from DIGlobalVariable. This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
2016-12-20 10:09:43 +08:00
; CHECK-NOT: DW_TAG
; CHECK: DW_TAG
; CHECK: DW_TAG_variable
; CHECK-NEXT: DW_AT_name {{.*}}"part_const"
; CHECK-NOT: DW_TAG
[dwarfdump] Pretty print location expressions and location lists Summary: Based on Fred's patch here: https://reviews.llvm.org/D6771 I can't seem to commandeer the old review, so I'm creating a new one. With that change the locations exrpessions are pretty printed inline in the DIE tree. The output looks like this for debug_loc entries: DW_AT_location [DW_FORM_data4] (0x00000000 0x0000000000000001 - 0x000000000000000b: DW_OP_consts +3 0x000000000000000b - 0x0000000000000012: DW_OP_consts +7 0x0000000000000012 - 0x000000000000001b: DW_OP_reg0 RAX, DW_OP_piece 0x4 0x000000000000001b - 0x0000000000000024: DW_OP_breg5 RDI+0) And like this for debug_loc.dwo entries: DW_AT_location [DW_FORM_sec_offset] (0x00000000 Addr idx 2 (w/ length 190): DW_OP_consts +0, DW_OP_stack_value Addr idx 3 (w/ length 23): DW_OP_reg0 RAX, DW_OP_piece 0x4) Simple locations without ranges are printed inline: DW_AT_location [DW_FORM_block1] (DW_OP_reg4 RSI, DW_OP_piece 0x4, DW_OP_bit_piece 0x20 0x0) The debug_loc(.dwo) dumping in changed accordingly to factor the code. Reviewers: dblaikie, aprantl, friss Subscribers: mgorny, javed.absar, hiraditya, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D37123 llvm-svn: 312042
2017-08-30 05:41:21 +08:00
; CHECK: DW_AT_location [DW_FORM_exprloc] (DW_OP_addr 0x8, DW_OP_piece 0x4, DW_OP_constu 0x2, DW_OP_stack_value, DW_OP_piece 0x4)
[IR] Remove the DIExpression field from DIGlobalVariable. This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
2016-12-20 10:09:43 +08:00
; [0x0000000000000008], piece 0x00000004, constu 0x00000002, stack-value, piece 0x00000004
; CHECK-NOT: DW_TAG
; CHECK: DW_TAG_variable
; CHECK-NEXT: DW_AT_name {{.*}}"full_const"
; CHECK-NOT: DW_TAG
[dwarfdump] Pretty print location expressions and location lists Summary: Based on Fred's patch here: https://reviews.llvm.org/D6771 I can't seem to commandeer the old review, so I'm creating a new one. With that change the locations exrpessions are pretty printed inline in the DIE tree. The output looks like this for debug_loc entries: DW_AT_location [DW_FORM_data4] (0x00000000 0x0000000000000001 - 0x000000000000000b: DW_OP_consts +3 0x000000000000000b - 0x0000000000000012: DW_OP_consts +7 0x0000000000000012 - 0x000000000000001b: DW_OP_reg0 RAX, DW_OP_piece 0x4 0x000000000000001b - 0x0000000000000024: DW_OP_breg5 RDI+0) And like this for debug_loc.dwo entries: DW_AT_location [DW_FORM_sec_offset] (0x00000000 Addr idx 2 (w/ length 190): DW_OP_consts +0, DW_OP_stack_value Addr idx 3 (w/ length 23): DW_OP_reg0 RAX, DW_OP_piece 0x4) Simple locations without ranges are printed inline: DW_AT_location [DW_FORM_block1] (DW_OP_reg4 RSI, DW_OP_piece 0x4, DW_OP_bit_piece 0x20 0x0) The debug_loc(.dwo) dumping in changed accordingly to factor the code. Reviewers: dblaikie, aprantl, friss Subscribers: mgorny, javed.absar, hiraditya, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D37123 llvm-svn: 312042
2017-08-30 05:41:21 +08:00
; CHECK: DW_AT_location [DW_FORM_exprloc] (DW_OP_constu 0x1, DW_OP_stack_value, DW_OP_piece 0x4, DW_OP_constu 0x2, DW_OP_stack_value, DW_OP_piece 0x4)
[IR] Remove the DIExpression field from DIGlobalVariable. This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
2016-12-20 10:09:43 +08:00
; CHECK-NOT: DW_TAG
@point.y = global i32 2, align 4, !dbg !13
@point.x = global i32 1, align 4, !dbg !12
Fix a bug when emitting debug info for partially constant global variables. While fixing a malformed testcase, I discovered that the code exercised by it was wrong, too. llvm-svn: 298664
2017-03-24 07:35:00 +08:00
@part_const.x = global i32 1, align 4, !dbg !14
[IR] Remove the DIExpression field from DIGlobalVariable. This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
2016-12-20 10:09:43 +08:00
!llvm.dbg.cu = !{!1}
!llvm.module.flags = !{!10, !11}
!0 = distinct !DIGlobalVariable(name: "point", scope: !1, file: !2, line: 1, type: !5, isLocal: false, isDefinition: true)
!1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2, producer: "clang", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4)
!2 = !DIFile(filename: "g.c", directory: "/")
!3 = !{}
Filter out non-constant DIGlobalVariableExpressions reachable via the CU They won't affect the DWARF output, but they will mess with the sorting of the fragments. This fixes the crash reported in PR34159. https://bugs.llvm.org/show_bug.cgi?id=34159 llvm-svn: 311217
2017-08-19 09:15:06 +08:00
!4 = !{!12, !13, !14, !15, !17, !18, !20}
[IR] Remove the DIExpression field from DIGlobalVariable. This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
2016-12-20 10:09:43 +08:00
!5 = distinct !DICompositeType(tag: DW_TAG_structure_type, file: !2, line: 1, size: 64, elements: !6)
!6 = !{!7, !9}
!7 = !DIDerivedType(tag: DW_TAG_member, name: "x", scope: !5, file: !2, line: 1, baseType: !8, size: 32)
!8 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!9 = !DIDerivedType(tag: DW_TAG_member, name: "y", scope: !5, file: !2, line: 1, baseType: !8, size: 32, offset: 32)
!10 = !{i32 2, !"Dwarf Version", i32 4}
!11 = !{i32 2, !"Debug Info Version", i32 3}
!12 = !DIGlobalVariableExpression(var: !0, expr: !DIExpression(DW_OP_LLVM_fragment, 0, 32))
!13 = !DIGlobalVariableExpression(var: !0, expr: !DIExpression(DW_OP_LLVM_fragment, 32, 32))
!14 = !DIGlobalVariableExpression(var: !16, expr: !DIExpression(DW_OP_LLVM_fragment, 0, 32))
!15 = !DIGlobalVariableExpression(var: !16, expr: !DIExpression(DW_OP_constu, 2,
DW_OP_stack_value, DW_OP_LLVM_fragment, 32, 32))
!16 = distinct !DIGlobalVariable(name: "part_const", scope: !1, file: !2, line: 1, type: !5, isLocal: false, isDefinition: true)
!17 = !DIGlobalVariableExpression(var: !19, expr: !DIExpression(DW_OP_constu, 1,
DW_OP_stack_value, DW_OP_LLVM_fragment, 0, 32))
!18 = !DIGlobalVariableExpression(var: !19, expr: !DIExpression(DW_OP_constu, 2,
DW_OP_stack_value, DW_OP_LLVM_fragment, 32, 32))
!19 = distinct !DIGlobalVariable(name: "full_const", scope: !1, file: !2, line: 1, type: !5, isLocal: false, isDefinition: true)
Filter out non-constant DIGlobalVariableExpressions reachable via the CU They won't affect the DWARF output, but they will mess with the sorting of the fragments. This fixes the crash reported in PR34159. https://bugs.llvm.org/show_bug.cgi?id=34159 llvm-svn: 311217
2017-08-19 09:15:06 +08:00
!20 = !DIGlobalVariableExpression(var: !0)