Page MenuHomePhabricator

[PS4] handle dllimport/export w.r.t vtables/rtti
Needs ReviewPublic

Authored by bd1976llvm on Dec 14 2020, 3:59 AM.



The existing Windows Itanium patches for dllimport/export behaviour w.r.t vtables/rtti can't be adopted for PS4 due to backwards compatibility reasons (see comments on

This review is for adding our PS4 scheme for this to Clang.

This is somewhat of a WIP. I am aware that some of these patches seem a bit awkwardly placed. Any assistance in how to refactor these patches would be extremely helpful.

Diff Detail

Event Timeline

bd1976llvm requested review of this revision.Dec 14 2020, 3:59 AM
bd1976llvm created this revision.
compnerd added inline comments.Dec 14 2020, 9:27 AM

Please reflow the comment (or clang-format)


Can this not be const auto *D : RD->noload_decls()?


I think that the additional conditional and early break are a bit easier to read.


I'm having a hard time following this comment.

I don't think that "Within the context of the Itanium C++ ABI, we want to mimic this MS behavior." adds any value.

What exactly does "defined in this TU/externally" mean? TU or defined externally means everywhere, no?

What is the "MS constraint"?


Please reflow the text (or clang-format)


I'm confused - does PS4 use a custom scheme or the MS ABI rules?

bd1976llvm added inline comments.Dec 14 2020, 6:15 PM

I will reword.

What is the "MS constraint"?

This is the constraint from the first sentence: "when dllimport/exporting only certain members of a class (rather than the non-inline virtual methods must be dllimported/exported, otherwise a link error will result". This constraint is documented here: as "If you have a class in which you are using selective member import/export with virtual functions, the functions must be in the exportable interface or defined inline (visible to the client).".

What exactly does "defined in this TU/externally" mean? TU or defined externally means everywhere, no?

Sorry badly phrased, try: "For classes using selective member import/export: We dllimport the vtable if it is defined externally and all the non-inline virtual methods are marked dllimport. We dllexport the vtable if it is defined in this TU and all the non-inline virtual methods are marked dllexport. Otherwise the vtable is not imported or exported. With this scheme links succeed in circumstances where they would succeed for Microsoft toolchains and fail with a linker error (missing vtable for struct) in circumstances where MS toolchains would give a linker error.

Hope that makes it clearer. There is a wordier comment in the attached test explaining this.


Sorry. Confusingly written :( The "custom scheme" I'm referring to is the patches in this review. The goal is to match the MS toolchain behaviour for dllimport/export on classes with vtables. This comment should probably just state: " We export the typeinfo in the same circumstances as the vtable is exported.".

bd1976llvm marked 6 inline comments as done.

Thanks for the suggestions. I have reworded the comments so that they are hopefully much clearer.

I have added this patch to along with some end to end tests to show the scei vendor windows-itanium behaviour. From the 'wi-test/test/dll_vtable_missing/' test you can see that the link error given by the scei vendor variant is more consistent than the standard windows-itanium. Both variants should be equivalent in terms of runtime behaviour.