maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Modules/DebugInfoTransitiveImport.m

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

29 lines
1.1 KiB
Mathematica
Raw Normal View History

Debug Info: When building a module, emit skeleton CUs for imported modules. llvm-svn: 248184
2015-09-22 01:48:37 +08:00
// RUN: rm -rf %t
Stop messing with the 'g' group of options in CompilerInvocation. With this change, most 'g' options are rejected by CompilerInvocation. They remain only as Driver options. The new way to request debug info from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}" and "-dwarf-version={2|3|4}". In the absence of a command-line option to specify Dwarf version, the Toolchain decides it, rather than placing Toolchain-specific logic in CompilerInvocation. Also fix a bug in the Windows compatibility argument parsing in which the "rightmost argument wins" principle failed. Differential Revision: http://reviews.llvm.org/D13221 llvm-svn: 249655
2015-10-08 12:24:12 +08:00
// RUN: %clang_cc1 -fmodules -fmodule-format=obj -debug-info-kind=limited -dwarf-ext-refs \
Debug Info: When building a module, emit skeleton CUs for imported modules. llvm-svn: 248184
2015-09-22 01:48:37 +08:00
// RUN: -fimplicit-module-maps -fmodules-cache-path=%t -I %S/Inputs \
[modules][debuginfo] Only include imported modules when targeting LLDB These constructs are only applicable to a debugger capable of loading a Clang AST, so omit them for brevity when not doing so. We could potentially propagate more of CodeGenOptions through the ObjectFilePCGContainerOperations for consistency (so the next person who adds some CodeGenOpts feature that tweaks debug info output doesn't get caught by this), so I'm open to objections/alternatives there, but went with this for now. Tested just a couple of basic cases (one direct, one indirect (through the ObjectFilePCHContainerOperations) & fixed up other cases to pass the -debugger-tuning flag as appropriate. llvm-svn: 268460
2016-05-04 07:06:40 +08:00
// RUN: %s -mllvm -debug-only=pchcontainer -debugger-tuning=lldb 2>&1 | FileCheck %s
Debug Info: When building a module, emit skeleton CUs for imported modules. llvm-svn: 248184
2015-09-22 01:48:37 +08:00
// REQUIRES: asserts
@import diamond_left;
Module Debugging: Use the clang module signature as the module's dwo_id when building a module. Clang already records the module signature when building a skeleton CU to reference a clang module. Matching the id in the skeleton with the one in the module allows a DWARF consumer to verify that they found the correct version of the module without them needing to know about the clang module format. llvm-svn: 248345
2015-09-23 07:26:43 +08:00
// Definition of top:
// CHECK: !DICompileUnit({{.*}}dwoId:
// CHECK: !DIFile({{.*}}diamond_top.h
// Definition of left:
// CHECK: !DICompileUnit({{.*}}dwoId:
Update for LLVM IR metadata changes (DIImportedEntity now needs a DIFile). <rdar://problem/33357889> https://bugs.llvm.org/show_bug.cgi?id=33822 Differential Revision: https://reviews.llvm.org/D35583 llvm-svn: 308399
2017-07-19 08:09:58 +08:00
// CHECK: ![[LEFT:[0-9]+]] = !DIFile({{.*}}diamond_left.h
Debug Info: When building a module, emit skeleton CUs for imported modules. llvm-svn: 248184
2015-09-22 01:48:37 +08:00
// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration,
Update for LLVM IR metadata changes (DIImportedEntity now needs a DIFile). <rdar://problem/33357889> https://bugs.llvm.org/show_bug.cgi?id=33822 Differential Revision: https://reviews.llvm.org/D35583 llvm-svn: 308399
2017-07-19 08:09:58 +08:00
// CHECK-SAME: entity: ![[MODULE:.*]], file: ![[LEFT]], line: 3)
Debug Info: When building a module, emit skeleton CUs for imported modules. llvm-svn: 248184
2015-09-22 01:48:37 +08:00
// CHECK: ![[MODULE]] = !DIModule(scope: null, name: "diamond_top"
Module Debugging: Use the clang module signature as the module's dwo_id when building a module. Clang already records the module signature when building a skeleton CU to reference a clang module. Matching the id in the skeleton with the one in the module allows a DWARF consumer to verify that they found the correct version of the module without them needing to know about the clang module format. llvm-svn: 248345
2015-09-23 07:26:43 +08:00
// Skeleton for top:
// CHECK: !DICompileUnit({{.*}}splitDebugFilename: {{.*}}diamond_top{{.*}}dwoId:
Debug Info: When building a module, emit skeleton CUs for imported modules. llvm-svn: 248184
2015-09-22 01:48:37 +08:00
[modules][debuginfo] Only include imported modules when targeting LLDB These constructs are only applicable to a debugger capable of loading a Clang AST, so omit them for brevity when not doing so. We could potentially propagate more of CodeGenOptions through the ObjectFilePCGContainerOperations for consistency (so the next person who adds some CodeGenOpts feature that tweaks debug info output doesn't get caught by this), so I'm open to objections/alternatives there, but went with this for now. Tested just a couple of basic cases (one direct, one indirect (through the ObjectFilePCHContainerOperations) & fixed up other cases to pass the -debugger-tuning flag as appropriate. llvm-svn: 268460
2016-05-04 07:06:40 +08:00
// RUN: rm -rf %t
// RUN: %clang_cc1 -fmodules -fmodule-format=obj -debug-info-kind=limited -dwarf-ext-refs \
// RUN: -fimplicit-module-maps -fmodules-cache-path=%t -I %S/Inputs \
// RUN: %s -mllvm -debug-only=pchcontainer 2>&1 | FileCheck %s --check-prefix=NOIMPORT
// NOIMPORT-NOT: !DIImportedEntity