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/xray-split-dwarf-interactio...

85 lines
3.9 KiB
LLVM
Raw Normal View History

[XRay][DebugInfo] Update the test to use a specific target Follow-up to D37791. llvm-svn: 313243
2017-09-14 17:58:25 +08:00
; RUN: llc -mtriple=x86_64-pc-linux -split-dwarf-file=input.dwo -O3 \
[XRay][CodeGen] Use the current function symbol as the associated symbol for the instrumentation map Summary: XRay had been assuming that the previous section is the "text" section of the function when lowering the instrumentation map. Unfortunately this is not a safe assumption, because we may be coming from lowering debug type information for the function being lowered. This fixes an issue with combining -gsplit-dwarf, -generate-type-units, -debug-compile and -fxray-instrument for sole member functions. When the split dwarf section is stripped, we're left with references from the xray_instr_map to the debug section. The change now uses the function's symbol instead of the previous section's start symbol. We found the bug while attempting to strip the split debug sections off an XRay-instrumented object file, which had a peculiar edge-case for single-function classes where the single function is being lowered. Because XRay had assocaited the instrumentation map for a function to the debug types section instead of the function's section, the objcopy call will fail due to the misplaced reference from the xray_instr_map section. Reviewers: pcc, dblaikie, echristo Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D37791 llvm-svn: 313233
2017-09-14 15:08:23 +08:00
; RUN: -function-sections -data-sections \
; RUN: -relocation-model=pic -filetype=asm \
[XRay][DebugInfo] Remove -debug-compile from test invocation of llc This breaks bootstrap builds, and is actually unnecessary. Tested locally and it seems we can remove -debug-comile just fine. Follow-up to D37791. llvm-svn: 313238
2017-09-14 15:54:54 +08:00
; RUN: -generate-type-units -o - %s | \
[XRay][CodeGen] Use the current function symbol as the associated symbol for the instrumentation map Summary: XRay had been assuming that the previous section is the "text" section of the function when lowering the instrumentation map. Unfortunately this is not a safe assumption, because we may be coming from lowering debug type information for the function being lowered. This fixes an issue with combining -gsplit-dwarf, -generate-type-units, -debug-compile and -fxray-instrument for sole member functions. When the split dwarf section is stripped, we're left with references from the xray_instr_map to the debug section. The change now uses the function's symbol instead of the previous section's start symbol. We found the bug while attempting to strip the split debug sections off an XRay-instrumented object file, which had a peculiar edge-case for single-function classes where the single function is being lowered. Because XRay had assocaited the instrumentation map for a function to the debug types section instead of the function's section, the objcopy call will fail due to the misplaced reference from the xray_instr_map section. Reviewers: pcc, dblaikie, echristo Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D37791 llvm-svn: 313233
2017-09-14 15:08:23 +08:00
; RUN: FileCheck %s --check-prefix=CHECK-ASM
[XRay][DebugInfo] Update the test to use a specific target Follow-up to D37791. llvm-svn: 313243
2017-09-14 17:58:25 +08:00
; RUN: llc -mtriple=x86_64-pc-linux -split-dwarf-file=input.dwo -O3 \
[XRay][CodeGen] Use the current function symbol as the associated symbol for the instrumentation map Summary: XRay had been assuming that the previous section is the "text" section of the function when lowering the instrumentation map. Unfortunately this is not a safe assumption, because we may be coming from lowering debug type information for the function being lowered. This fixes an issue with combining -gsplit-dwarf, -generate-type-units, -debug-compile and -fxray-instrument for sole member functions. When the split dwarf section is stripped, we're left with references from the xray_instr_map to the debug section. The change now uses the function's symbol instead of the previous section's start symbol. We found the bug while attempting to strip the split debug sections off an XRay-instrumented object file, which had a peculiar edge-case for single-function classes where the single function is being lowered. Because XRay had assocaited the instrumentation map for a function to the debug types section instead of the function's section, the objcopy call will fail due to the misplaced reference from the xray_instr_map section. Reviewers: pcc, dblaikie, echristo Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D37791 llvm-svn: 313233
2017-09-14 15:08:23 +08:00
; RUN: -function-sections -data-sections \
; RUN: -relocation-model=pic -filetype=obj \
[XRay][DebugInfo] Remove -debug-compile from test invocation of llc This breaks bootstrap builds, and is actually unnecessary. Tested locally and it seems we can remove -debug-comile just fine. Follow-up to D37791. llvm-svn: 313238
2017-09-14 15:54:54 +08:00
; RUN: -generate-type-units -o - %s | \
[XRay][CodeGen] Use the current function symbol as the associated symbol for the instrumentation map Summary: XRay had been assuming that the previous section is the "text" section of the function when lowering the instrumentation map. Unfortunately this is not a safe assumption, because we may be coming from lowering debug type information for the function being lowered. This fixes an issue with combining -gsplit-dwarf, -generate-type-units, -debug-compile and -fxray-instrument for sole member functions. When the split dwarf section is stripped, we're left with references from the xray_instr_map to the debug section. The change now uses the function's symbol instead of the previous section's start symbol. We found the bug while attempting to strip the split debug sections off an XRay-instrumented object file, which had a peculiar edge-case for single-function classes where the single function is being lowered. Because XRay had assocaited the instrumentation map for a function to the debug types section instead of the function's section, the objcopy call will fail due to the misplaced reference from the xray_instr_map section. Reviewers: pcc, dblaikie, echristo Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D37791 llvm-svn: 313233
2017-09-14 15:08:23 +08:00
; RUN: llvm-readelf -sections | \
; RUN: FileCheck %s --check-prefix=CHECK-ELF
; Created from `clang++ -fxray-instrument -gsplit-dwarf -fdebug-types-section
; -ffunction-sections -fdata-sections -emit-llvm -S input.cc`:
; input.cc:
;
; class a {
; int b();
; };
; int a::b() {
; for (;;)
; ;
; }
;
; In this test we want to make sure that the xray_instr_map section for
; `a::b()` is actually associated with the function's symbol instead of the
; .debug_types.dwo section.
;
; CHECK-ASM: xray_fn_idx,"awo",@progbits,_ZN1a1bEv,unique,1
;
; CHECK-ELF-DAG: [[FSECT:[0-9]+]]] .text._ZN1a1bEv PROGBITS
; CHECK-ELF-DAG: [{{.*}}] .debug_types.dwo PROGBITS
; CHECK-ELF-DAG: [{{.*}}] xray_instr_map PROGBITS {{.*}} {{.*}} {{.*}} {{.*}} WAL [[FSECT]]
target triple = "x86_64-pc-linux"
%class.a = type { i8 }
; Function Attrs: nounwind readnone uwtable
define i32 @_ZN1a1bEv(%class.a* nocapture readnone) local_unnamed_addr #0 align 2 !dbg !8 {
tail call void @llvm.dbg.value(metadata %class.a* %0, metadata !17, metadata !DIExpression()), !dbg !19
br label %2, !dbg !20
; <label>:2: ; preds = %2, %1
br label %2, !dbg !21, !llvm.loop !25
}
; Function Attrs: nounwind readnone speculatable
declare void @llvm.dbg.value(metadata, metadata, metadata) #1
attributes #0 = { nounwind readnone uwtable "xray-instruction-threshold"="200" }
attributes #1 = { nounwind readnone speculatable }
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!3, !4, !5, !6}
!llvm.ident = !{!7}
!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version trunk (trunk r312634)", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, debugInfoForProfiling: true)
!1 = !DIFile(filename: "input.cc", directory: "/usr/local/google/home/dberris/tmp")
!2 = !{}
!3 = !{i32 2, !"Debug Info Version", i32 3}
!4 = !{i32 1, !"wchar_size", i32 4}
!5 = !{i32 7, !"PIC Level", i32 2}
!6 = !{i32 7, !"PIE Level", i32 2}
!7 = !{!"clang version trunk (trunk r312634)"}
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label. In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
2018-05-09 10:40:45 +08:00
!8 = distinct !DISubprogram(name: "b", linkageName: "_ZN1a1bEv", scope: !9, file: !1, line: 4, type: !12, isLocal: false, isDefinition: true, scopeLine: 4, flags: DIFlagPrototyped, isOptimized: true, unit: !0, declaration: !11, retainedNodes: !16)
[XRay][CodeGen] Use the current function symbol as the associated symbol for the instrumentation map Summary: XRay had been assuming that the previous section is the "text" section of the function when lowering the instrumentation map. Unfortunately this is not a safe assumption, because we may be coming from lowering debug type information for the function being lowered. This fixes an issue with combining -gsplit-dwarf, -generate-type-units, -debug-compile and -fxray-instrument for sole member functions. When the split dwarf section is stripped, we're left with references from the xray_instr_map to the debug section. The change now uses the function's symbol instead of the previous section's start symbol. We found the bug while attempting to strip the split debug sections off an XRay-instrumented object file, which had a peculiar edge-case for single-function classes where the single function is being lowered. Because XRay had assocaited the instrumentation map for a function to the debug types section instead of the function's section, the objcopy call will fail due to the misplaced reference from the xray_instr_map section. Reviewers: pcc, dblaikie, echristo Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D37791 llvm-svn: 313233
2017-09-14 15:08:23 +08:00
!9 = distinct !DICompositeType(tag: DW_TAG_class_type, name: "a", file: !1, line: 1, size: 8, elements: !10, identifier: "_ZTS1a")
!10 = !{!11}
!11 = !DISubprogram(name: "b", linkageName: "_ZN1a1bEv", scope: !9, file: !1, line: 2, type: !12, isLocal: false, isDefinition: false, scopeLine: 2, flags: DIFlagPrototyped, isOptimized: true)
!12 = !DISubroutineType(types: !13)
!13 = !{!14, !15}
!14 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!15 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !9, size: 64, flags: DIFlagArtificial | DIFlagObjectPointer)
!16 = !{!17}
!17 = !DILocalVariable(name: "this", arg: 1, scope: !8, type: !18, flags: DIFlagArtificial | DIFlagObjectPointer)
!18 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !9, size: 64)
!19 = !DILocation(line: 0, scope: !8)
!20 = !DILocation(line: 5, column: 3, scope: !8)
!21 = !DILocation(line: 5, column: 3, scope: !22)
!22 = !DILexicalBlockFile(scope: !23, file: !1, discriminator: 2)
!23 = distinct !DILexicalBlock(scope: !24, file: !1, line: 5, column: 3)
!24 = distinct !DILexicalBlock(scope: !8, file: !1, line: 5, column: 3)
!25 = distinct !{!25, !26, !27}
!26 = !DILocation(line: 5, column: 3, scope: !24)
!27 = !DILocation(line: 6, column: 5, scope: !24)