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/Generic/debug-names-empty-name.ll

39 lines
1.6 KiB
LLVM
Raw Normal View History

[CodeGen/AccelTable]: Don't emit accelerator entries for functions with no names Summary: We were emitting accelerator entries for functions with no name, which is contrary to the DWARF v5 spec: "All other (i.e., *not* DW_TAG_namespace) debugging information entries without a DW_AT_name attribute are excluded." Besides that, a name table entry with an empty string as a key is fairly useless. We can sometimes end up with functions which have a DW_AT_linkage_name but no DW_AT_name. One such example is the global-constructor-initialization functions, which C++ compilers synthesize for each compilation unit with global constructors. A very strict reading of the DWARF v5 spec would suggest that we should not even emit the accelerator entry for the linkage name in this case, but I don't think we should go that far. I found this when running the dwarf verifier over llvm codebase compiled with DWARF v5 accelerator tables. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: vleschuk, clayborg, echristo, probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D45367 llvm-svn: 329552
2018-04-09 16:41:57 +08:00
; REQUIRES: object-emission
Make the test case from r329552 more portable - when tuning for SCE debugger (default for ps4 targets), we will not emit the DW_AT_linkage_name, which this test needs. I explicitly set the debugger tuning parameter to get the attribute always. - darwin targets did not like the "section .text.startup" fragment of the test. This is not actually needed for the test, so I remove it. llvm-svn: 329555
2018-04-09 17:11:40 +08:00
; RUN: %llc_dwarf -debugger-tune=lldb -accel-tables=Dwarf -filetype=obj -o %t < %s
[CodeGen/AccelTable]: Don't emit accelerator entries for functions with no names Summary: We were emitting accelerator entries for functions with no name, which is contrary to the DWARF v5 spec: "All other (i.e., *not* DW_TAG_namespace) debugging information entries without a DW_AT_name attribute are excluded." Besides that, a name table entry with an empty string as a key is fairly useless. We can sometimes end up with functions which have a DW_AT_linkage_name but no DW_AT_name. One such example is the global-constructor-initialization functions, which C++ compilers synthesize for each compilation unit with global constructors. A very strict reading of the DWARF v5 spec would suggest that we should not even emit the accelerator entry for the linkage name in this case, but I don't think we should go that far. I found this when running the dwarf verifier over llvm codebase compiled with DWARF v5 accelerator tables. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: vleschuk, clayborg, echristo, probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D45367 llvm-svn: 329552
2018-04-09 16:41:57 +08:00
; RUN: llvm-dwarfdump -find=_GLOBAL__sub_I__ %t | FileCheck --check-prefix=INFO %s
; RUN: llvm-dwarfdump -debug-names %t | FileCheck --check-prefix=NAMES %s
; RUN: llvm-dwarfdump -debug-names -verify %t | FileCheck --check-prefix=VERIFY %s
; The debug info entry should not have a DW_AT_name, only a DW_AT_linkage_name.
; INFO: DW_TAG_subprogram
; INFO-NOT: DW_AT_name
; INFO: DW_AT_linkage_name ("_GLOBAL__sub_I__")
; INFO-NOT: DW_AT_name
; The accelerator table should contain only one entry.
; NAMES: Name count: 1
; And it should be the linkage name.
; NAMES: String: 0x{{[0-9a-f]*}} "_GLOBAL__sub_I__"
; Verification should succeed.
; VERIFY: No errors.
Make the test case from r329552 more portable - when tuning for SCE debugger (default for ps4 targets), we will not emit the DW_AT_linkage_name, which this test needs. I explicitly set the debugger tuning parameter to get the attribute always. - darwin targets did not like the "section .text.startup" fragment of the test. This is not actually needed for the test, so I remove it. llvm-svn: 329555
2018-04-09 17:11:40 +08:00
define internal void @_GLOBAL__sub_I__() !dbg !7 {
[CodeGen/AccelTable]: Don't emit accelerator entries for functions with no names Summary: We were emitting accelerator entries for functions with no name, which is contrary to the DWARF v5 spec: "All other (i.e., *not* DW_TAG_namespace) debugging information entries without a DW_AT_name attribute are excluded." Besides that, a name table entry with an empty string as a key is fairly useless. We can sometimes end up with functions which have a DW_AT_linkage_name but no DW_AT_name. One such example is the global-constructor-initialization functions, which C++ compilers synthesize for each compilation unit with global constructors. A very strict reading of the DWARF v5 spec would suggest that we should not even emit the accelerator entry for the linkage name in this case, but I don't think we should go that far. I found this when running the dwarf verifier over llvm codebase compiled with DWARF v5 accelerator tables. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: vleschuk, clayborg, echristo, probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D45367 llvm-svn: 329552
2018-04-09 16:41:57 +08:00
entry:
ret void
}
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!3, !4, !5}
!llvm.ident = !{!6}
!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 7.0.0 (trunk 329378) (llvm/trunk 329379)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, globals: !2)
!1 = !DIFile(filename: "-", directory: "/usr/local/google/home/labath/ll/build/opt")
!2 = !{}
!3 = !{i32 2, !"Dwarf Version", i32 4}
!4 = !{i32 2, !"Debug Info Version", i32 3}
!5 = !{i32 1, !"wchar_size", i32 4}
!6 = !{!"clang version 7.0.0 (trunk 329378) (llvm/trunk 329379)"}
[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
!7 = distinct !DISubprogram(linkageName: "_GLOBAL__sub_I__", scope: !1, file: !1, type: !8, isLocal: true, isDefinition: true, flags: DIFlagArtificial, isOptimized: false, unit: !0, retainedNodes: !2)
[CodeGen/AccelTable]: Don't emit accelerator entries for functions with no names Summary: We were emitting accelerator entries for functions with no name, which is contrary to the DWARF v5 spec: "All other (i.e., *not* DW_TAG_namespace) debugging information entries without a DW_AT_name attribute are excluded." Besides that, a name table entry with an empty string as a key is fairly useless. We can sometimes end up with functions which have a DW_AT_linkage_name but no DW_AT_name. One such example is the global-constructor-initialization functions, which C++ compilers synthesize for each compilation unit with global constructors. A very strict reading of the DWARF v5 spec would suggest that we should not even emit the accelerator entry for the linkage name in this case, but I don't think we should go that far. I found this when running the dwarf verifier over llvm codebase compiled with DWARF v5 accelerator tables. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: vleschuk, clayborg, echristo, probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D45367 llvm-svn: 329552
2018-04-09 16:41:57 +08:00
!8 = !DISubroutineType(types: !2)