maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/debug-info-dllimport-base-c...

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

54 lines
1.5 KiB
C++
Raw Normal View History

Emit debug info for dynamic classes if they are imported from a DLL. With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger. The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows. Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc. llvm-svn: 278861
2016-08-17 06:11:18 +08:00
// RUN: %clang_cc1 -triple i386-pc-windows -emit-llvm -gcodeview -debug-info-kind=limited -fms-compatibility %s -x c++ -o - | FileCheck %s
// Ensure we emit debug info for the full definition of base classes that will
// be imported from a DLL. Otherwise, the debugger wouldn't be able to show the
// members.
[DebugInfo] Deduplicate debug info limiting logic We should be doing the same checks when a type is completed as we do when a complete type is used during emission. Previously, we duplicated the logic, and it got out of sync. This could be observed with dllimported classes. Also reduce a test case for this slightly. Implementing review feedback from David Blaikie on r281057. llvm-svn: 281278
2016-09-13 08:01:23 +08:00
// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "ImportedAfterCompletion",
// CHECK-NOT: DIFlagFwdDecl
// CHECK-SAME: ){{$}}
[codeview] Extend the heuristic for detecting classes imported from DLLs If a dynamic class contains a dllimport method, then assume the class may not be constructed in this DLL, and therefore the vtable will live in a different PDB. This heuristic is still incomplete, and will miss things like abstract base classes that are only constructed on one side of the DLL interface. That said, this heuristic does detect some cases that are currently problematic, and may be useful to other projects that don't use many DLLs. llvm-svn: 281053
2016-09-10 00:27:04 +08:00
// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "OutOfLineCtor",
// CHECK-SAME: DIFlagFwdDecl
// CHECK-SAME: ){{$}}
Emit debug info for dynamic classes if they are imported from a DLL. With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger. The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows. Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc. llvm-svn: 278861
2016-08-17 06:11:18 +08:00
// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "ImportedBase",
// CHECK-NOT: DIFlagFwdDecl
// CHECK-SAME: ){{$}}
[codeview] Extend the heuristic for detecting classes imported from DLLs If a dynamic class contains a dllimport method, then assume the class may not be constructed in this DLL, and therefore the vtable will live in a different PDB. This heuristic is still incomplete, and will miss things like abstract base classes that are only constructed on one side of the DLL interface. That said, this heuristic does detect some cases that are currently problematic, and may be useful to other projects that don't use many DLLs. llvm-svn: 281053
2016-09-10 00:27:04 +08:00
// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "ImportedMethod",
// CHECK-NOT: DIFlagFwdDecl
// CHECK-SAME: ){{$}}
[DebugInfo] Deduplicate debug info limiting logic We should be doing the same checks when a type is completed as we do when a complete type is used during emission. Previously, we duplicated the logic, and it got out of sync. This could be observed with dllimported classes. Also reduce a test case for this slightly. Implementing review feedback from David Blaikie on r281057. llvm-svn: 281278
2016-09-13 08:01:23 +08:00
struct ImportedAfterCompletion;
ImportedAfterCompletion *force_fwd_decl;
struct __declspec(dllimport) ImportedAfterCompletion {
virtual ~ImportedAfterCompletion();
};
[codeview] Extend the heuristic for detecting classes imported from DLLs If a dynamic class contains a dllimport method, then assume the class may not be constructed in this DLL, and therefore the vtable will live in a different PDB. This heuristic is still incomplete, and will miss things like abstract base classes that are only constructed on one side of the DLL interface. That said, this heuristic does detect some cases that are currently problematic, and may be useful to other projects that don't use many DLLs. llvm-svn: 281053
2016-09-10 00:27:04 +08:00
struct OutOfLineCtor {
OutOfLineCtor();
virtual void Foo();
};
Emit debug info for dynamic classes if they are imported from a DLL. With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger. The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows. Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc. llvm-svn: 278861
2016-08-17 06:11:18 +08:00
struct __declspec(dllimport) ImportedBase {
ImportedBase();
virtual void Foo();
};
struct DerivedFromImported : public ImportedBase {};
[codeview] Extend the heuristic for detecting classes imported from DLLs If a dynamic class contains a dllimport method, then assume the class may not be constructed in this DLL, and therefore the vtable will live in a different PDB. This heuristic is still incomplete, and will miss things like abstract base classes that are only constructed on one side of the DLL interface. That said, this heuristic does detect some cases that are currently problematic, and may be useful to other projects that don't use many DLLs. llvm-svn: 281053
2016-09-10 00:27:04 +08:00
struct ImportedMethod {
ImportedMethod();
virtual void Foo();
static void __declspec(dllimport) create();
};
Emit debug info for dynamic classes if they are imported from a DLL. With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger. The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows. Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc. llvm-svn: 278861
2016-08-17 06:11:18 +08:00
int main() {
[DebugInfo] Deduplicate debug info limiting logic We should be doing the same checks when a type is completed as we do when a complete type is used during emission. Previously, we duplicated the logic, and it got out of sync. This could be observed with dllimported classes. Also reduce a test case for this slightly. Implementing review feedback from David Blaikie on r281057. llvm-svn: 281278
2016-09-13 08:01:23 +08:00
ImportedAfterCompletion c;
[codeview] Extend the heuristic for detecting classes imported from DLLs If a dynamic class contains a dllimport method, then assume the class may not be constructed in this DLL, and therefore the vtable will live in a different PDB. This heuristic is still incomplete, and will miss things like abstract base classes that are only constructed on one side of the DLL interface. That said, this heuristic does detect some cases that are currently problematic, and may be useful to other projects that don't use many DLLs. llvm-svn: 281053
2016-09-10 00:27:04 +08:00
OutOfLineCtor o;
Emit debug info for dynamic classes if they are imported from a DLL. With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger. The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows. Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc. llvm-svn: 278861
2016-08-17 06:11:18 +08:00
DerivedFromImported d;
[codeview] Extend the heuristic for detecting classes imported from DLLs If a dynamic class contains a dllimport method, then assume the class may not be constructed in this DLL, and therefore the vtable will live in a different PDB. This heuristic is still incomplete, and will miss things like abstract base classes that are only constructed on one side of the DLL interface. That said, this heuristic does detect some cases that are currently problematic, and may be useful to other projects that don't use many DLLs. llvm-svn: 281053
2016-09-10 00:27:04 +08:00
ImportedMethod m;
Emit debug info for dynamic classes if they are imported from a DLL. With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger. The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows. Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc. llvm-svn: 278861
2016-08-17 06:11:18 +08:00
}