RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 20:23:11 +01:00
Code Issues Projects Releases Wiki Activity
c9fceef173
llvm-mirror/test/DebugInfo/dwo.ll

24 lines
1.0 KiB
LLVM
Raw Normal View History

Debug Info: Emit the dwo_name only in skeleton CUs, not in DWOs. llvm-svn: 248340
2015-09-23 01:21:00 +02:00
; RUN: %llc_dwarf %s -filetype=obj -o %t
llvm-dwarfdump: Replace -debug-dump=sect option with individual options. As discussed on llvm-dev in http://lists.llvm.org/pipermail/llvm-dev/2017-September/117301.html this changes the command line interface of llvm-dwarfdump to match the one used by the dwarfdump utility shipping on macOS. In addition to being shorter to type this format also has the advantage of allowing more than one section to be specified at the same time. In a nutshell, with this change $ llvm-dwarfdump --debug-dump=info $ llvm-dwarfdump --debug-dump=apple-objc becomes $ dwarfdump --debug-info --apple-objc Differential Revision: https://reviews.llvm.org/D37714 llvm-svn: 312970
2017-09-12 00:59:45 +02:00
; RUN: llvm-dwarfdump -debug-info %t | FileCheck %s
Restore lit feature object-emission. Omit DebugInfo/Generic on XCore. D73568 removed the lit feature object-emission, because it was introduced for a target which did not support the integrated assembler, and that target no longer required the feature. XCore still does not support the integrated assembler, so a build with XCore as the default target fails tests requiring object-emission. This issue was not publicly visible because there was not a buildbot for XCore as the default target. We fixed the failures downstream. We now have builder clang-xcore-ubuntu-20-x64 on the staging buildmaster, which shows the failures. We would like to make upstream build green. Omit DebugInfo/Generic on XCore to avoid annotating 70 separate files. Differential Revision: https://reviews.llvm.org/D98508
2020-08-18 14:21:20 +02:00
; REQUIRES: default_triple, object-emission
Do a better job at emitting prefrabricated skeleton CUs. This is a better fix than r308708 for the problem introduced in r304020. It restores the skeleton CU testcases modified by that commit to their original form and most importantly ensures that frontend-generated skeleton CUs (such as used to point to Clang modules) come after the regular CUs. This broke for DICompileUnit nodes that don't have any immediate children because they are now constructed lazily instead of the order in which they are listed in !llvm.dbg.cu. After this commit we still don't guarantee that order, but we do guarantee that empty skeletons come last. Shipping versions of LLDB are very sensitive to the ordering of CUs. I'll track a fix for LLDB to be more permissive separately. This fixes a test failure in the LLDB testsuite. rdar://problem/33357252 llvm-svn: 309154
2017-07-26 20:48:32 +02:00
;
; CHECK: DW_TAG_compile_unit
; CHECK-NOT: dwo_id
;
; The skeleton must come second or LLDB may get confused.
Debug Info: Emit the dwo_name only in skeleton CUs, not in DWOs. llvm-svn: 248340
2015-09-23 01:21:00 +02:00
; CHECK: DW_TAG_compile_unit
; CHECK: DW_AT_GNU_dwo_id {{.*}}abcd
Do a better job at emitting prefrabricated skeleton CUs. This is a better fix than r308708 for the problem introduced in r304020. It restores the skeleton CU testcases modified by that commit to their original form and most importantly ensures that frontend-generated skeleton CUs (such as used to point to Clang modules) come after the regular CUs. This broke for DICompileUnit nodes that don't have any immediate children because they are now constructed lazily instead of the order in which they are listed in !llvm.dbg.cu. After this commit we still don't guarantee that order, but we do guarantee that empty skeletons come last. Shipping versions of LLDB are very sensitive to the ordering of CUs. I'll track a fix for LLDB to be more permissive separately. This fixes a test failure in the LLDB testsuite. rdar://problem/33357252 llvm-svn: 309154
2017-07-26 20:48:32 +02:00
; CHECK: DW_AT_GNU_dwo_name {{.*}}"my.dwo"
Debug Info: Emit the dwo_name only in skeleton CUs, not in DWOs. llvm-svn: 248340
2015-09-23 01:21:00 +02:00
Do a better job at emitting prefrabricated skeleton CUs. This is a better fix than r308708 for the problem introduced in r304020. It restores the skeleton CU testcases modified by that commit to their original form and most importantly ensures that frontend-generated skeleton CUs (such as used to point to Clang modules) come after the regular CUs. This broke for DICompileUnit nodes that don't have any immediate children because they are now constructed lazily instead of the order in which they are listed in !llvm.dbg.cu. After this commit we still don't guarantee that order, but we do guarantee that empty skeletons come last. Shipping versions of LLDB are very sensitive to the ordering of CUs. I'll track a fix for LLDB to be more permissive separately. This fixes a test failure in the LLDB testsuite. rdar://problem/33357252 llvm-svn: 309154
2017-07-26 20:48:32 +02:00
!llvm.dbg.cu = !{!7, !0}
Debug Info: Emit the dwo_name only in skeleton CUs, not in DWOs. llvm-svn: 248340
2015-09-23 01:21:00 +02:00
!llvm.module.flags = !{!3, !4}
Do a better job at emitting prefrabricated skeleton CUs. This is a better fix than r308708 for the problem introduced in r304020. It restores the skeleton CU testcases modified by that commit to their original form and most importantly ensures that frontend-generated skeleton CUs (such as used to point to Clang modules) come after the regular CUs. This broke for DICompileUnit nodes that don't have any immediate children because they are now constructed lazily instead of the order in which they are listed in !llvm.dbg.cu. After this commit we still don't guarantee that order, but we do guarantee that empty skeletons come last. Shipping versions of LLDB are very sensitive to the ordering of CUs. I'll track a fix for LLDB to be more permissive separately. This fixes a test failure in the LLDB testsuite. rdar://problem/33357252 llvm-svn: 309154
2017-07-26 20:48:32 +02:00
!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "Clang", isOptimized: false, runtimeVersion: 2, splitDebugFilename: "my.dwo", emissionKind: FullDebug, enums: !2, retainedTypes: !2, globals: !2, imports: !2, dwoId: 43981)
Debug Info: Emit the dwo_name only in skeleton CUs, not in DWOs. llvm-svn: 248340
2015-09-23 01:21:00 +02:00
!1 = !DIFile(filename: "<stdin>", directory: "/")
!2 = !{}
!3 = !{i32 2, !"Dwarf Version", i32 4}
!4 = !{i32 2, !"Debug Info Version", i32 3}
DebugInfo: Do not emit empty CUs Consistent with GCC and addresses a shortcoming with ThinLTO where many imported CUs may end up being empty (because the functions imported from them either ended up not being used (and were then discarded, since they're imported as available_externally) or optimized away entirely). Test cases previously testing empty CUs (either intentionally, or because they didn't need anything more complicated) had a trivial 'int' or similar basic type added to their retained types list. This is a first order approximation - a deeper implementation could do things like: 1) Be more lazy about construction of the CU - for example if two CUs containing a single identical retained type are linked together, with this change one of the two CUs will be produced but empty (since a duplicate type won't be produced). 2) Go further and invert all the CU links the same way the subprogram link is inverted - keep named CU lists of retained types, macros, etc, and have those link back to the CU. Then if they're emitted, the CU is emitted, but never otherwise - this would allow the metadata itself to be dropped earlier too, though it seems unlikely that's an important optimization as there shouldn't be many CUs relative to the number of other entities. llvm-svn: 304020
2017-05-26 20:52:56 +02:00
!5 = !{!6}
!6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
Do a better job at emitting prefrabricated skeleton CUs. This is a better fix than r308708 for the problem introduced in r304020. It restores the skeleton CU testcases modified by that commit to their original form and most importantly ensures that frontend-generated skeleton CUs (such as used to point to Clang modules) come after the regular CUs. This broke for DICompileUnit nodes that don't have any immediate children because they are now constructed lazily instead of the order in which they are listed in !llvm.dbg.cu. After this commit we still don't guarantee that order, but we do guarantee that empty skeletons come last. Shipping versions of LLDB are very sensitive to the ordering of CUs. I'll track a fix for LLDB to be more permissive separately. This fixes a test failure in the LLDB testsuite. rdar://problem/33357252 llvm-svn: 309154
2017-07-26 20:48:32 +02:00
!7 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "Clang", isOptimized: false, runtimeVersion: 2, emissionKind: FullDebug, retainedTypes: !5)
Reference in New Issue Copy Permalink