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/dllexport-vtable-thunks.cpp

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

25 lines
815 B
C++
Raw Normal View History

[windows-itanium] handle dllimport/export code paths separately and share with PS4 Similar to Windows Itanium, PS4 is also an Itanium C++ ABI variant which shares the goal of semantic compatibility with Microsoft C++ code that uses dllimport/export. This change introduces a new function to determine from the triple if an environment aims for compatibility with MS C++ code w.r.t to these attributes and guards the relevant code paths using that function. Differential Revision: https://reviews.llvm.org/D90299
2020-11-30 19:50:45 +08:00
// RUN: %clang_cc1 -triple x86_64-windows-gnu -fdeclspec -emit-llvm -o - %s | FileCheck %s -DDSO_ATTRS="dso_local dllexport"
// RUN: %clang_cc1 -triple x86_64-windows-itanium -fdeclspec -emit-llvm -o - %s | FileCheck %s -DDSO_ATTRS="dso_local dllexport"
// RUN: %clang_cc1 -triple x86_64-scei-ps4 -fdeclspec -emit-llvm -o - %s | FileCheck %s -DDSO_ATTRS=dllexport
[CodeGen] Propagate dllexport to thunks Under Windows Itanium, we need to export virtual and non-virtual thunks if the functions being thunked are exported. These thunks would previously inherit their dllexport attribute from the declaration, but r298330 changed declarations to not have dllexport attributes. We therefore need to add the dllexport attribute to the definition ourselves now. This is consistent with MinGW GCC's behavior. This redoes r306770 but limits the logic to Itanium. MicrosoftCXXABI's setThunkLinkage ensures that thunks aren't exported under that ABI, so I'm handling this in ItaniumCXXABI's setThunkLinkage for symmetry. We need to export these thunks because they can be referenced outside the library they're defined in. For example, if a child class without a key function inherits from a parent class with a key function, the parent's thunks will only be defined in the library with the key function, but the construction vtable for the parent in the child might be emitted outside the library (since the child doesn't have a key function), and it needs to reference the parent's thunks. We don't need to mark these thunks as imported since any references to them will occur in data, so the compiler can't generate the IAT load sequence anyway. Instead, we rely on the linker generating import thunks for the thunks. Differential Revision: https://reviews.llvm.org/D34972 llvm-svn: 308899
2017-07-25 01:16:27 +08:00
struct __declspec(dllexport) A {
virtual void m();
};
struct __declspec(dllexport) B {
virtual void m();
};
struct __declspec(dllexport) C : A, B {
virtual void m();
};
void C::m() {}
[windows-itanium] handle dllimport/export code paths separately and share with PS4 Similar to Windows Itanium, PS4 is also an Itanium C++ ABI variant which shares the goal of semantic compatibility with Microsoft C++ code that uses dllimport/export. This change introduces a new function to determine from the triple if an environment aims for compatibility with MS C++ code w.r.t to these attributes and guards the relevant code paths using that function. Differential Revision: https://reviews.llvm.org/D90299
2020-11-30 19:50:45 +08:00
// CHECK: define [[DSO_ATTRS]] void @_ZThn8_N1C1mEv
[CodeGen] Propagate dllexport to thunks Under Windows Itanium, we need to export virtual and non-virtual thunks if the functions being thunked are exported. These thunks would previously inherit their dllexport attribute from the declaration, but r298330 changed declarations to not have dllexport attributes. We therefore need to add the dllexport attribute to the definition ourselves now. This is consistent with MinGW GCC's behavior. This redoes r306770 but limits the logic to Itanium. MicrosoftCXXABI's setThunkLinkage ensures that thunks aren't exported under that ABI, so I'm handling this in ItaniumCXXABI's setThunkLinkage for symmetry. We need to export these thunks because they can be referenced outside the library they're defined in. For example, if a child class without a key function inherits from a parent class with a key function, the parent's thunks will only be defined in the library with the key function, but the construction vtable for the parent in the child might be emitted outside the library (since the child doesn't have a key function), and it needs to reference the parent's thunks. We don't need to mark these thunks as imported since any references to them will occur in data, so the compiler can't generate the IAT load sequence anyway. Instead, we rely on the linker generating import thunks for the thunks. Differential Revision: https://reviews.llvm.org/D34972 llvm-svn: 308899
2017-07-25 01:16:27 +08:00
struct Base {
virtual void m();
};
struct __declspec(dllexport) Derived : virtual Base {
virtual void m();
};
void Derived::m() {}
[windows-itanium] handle dllimport/export code paths separately and share with PS4 Similar to Windows Itanium, PS4 is also an Itanium C++ ABI variant which shares the goal of semantic compatibility with Microsoft C++ code that uses dllimport/export. This change introduces a new function to determine from the triple if an environment aims for compatibility with MS C++ code w.r.t to these attributes and guards the relevant code paths using that function. Differential Revision: https://reviews.llvm.org/D90299
2020-11-30 19:50:45 +08:00
// CHECK: define [[DSO_ATTRS]] void @_ZTv0_n24_N7Derived1mEv