[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In https://reviews.llvm.org/D43184#1005534, @mstorsjo wrote:

> In https://reviews.llvm.org/D43184#1005281, @smeenai wrote:
>
> >
>
>
> A related observation on the topic of this: There's a subtle difference between what both GCC and MSVC does here, compared to clang. The case with a single variable works the same in all of them, but if you have a struct with many initialized elements, GCC and MSVC will initialize as many as possible of them statically, and only fill in the dllimport ones via a dynamic initializer. clang, on the other hand, will not initialize anything statically at all if it emits a dynamic initializer.


The Qt bug is interesting, but I think we're doing the right thing here. C++ doesn't define any semantics for partially initialized objects. It's unclear if clang or GCC's way of doing things is better or not. With clang, you get to put the global in .bss, so it's not clear what makes for bigger code size.

In https://reviews.llvm.org/D43184#1008003, @mstorsjo wrote:

> In https://reviews.llvm.org/D43184#1005258, @rnk wrote:
>
> > Do you think we should do something like local vftables for itanium instead? Can we assume all methods in the vtable will be exported by the DLL exporting the class?
>
>
> Will this actually ever be needed for other vtables than cxxabi::class_type_info and the others from ItaniumRTTIBuilder::BuildVTablePointer? In what other cases are the vtables referred to from a statically initialized global? And for these vtables - there's no declaration of them at all within most translation units, so that'd require hardcoding all the content of these vtables in ItaniumRTTIBuilder.


Here's a case where a local vtable would help:

  struct __declspec(dllimport) A { virtual void a(); };
  struct __declspec(dllimport) B { virtual void b(); };
  struct __declspec(dllimport) C : A, B {
    void a() override;
    void b() override;
  };
  constexpr C c;

I'm suggesting we can make a DSO local copy of _ZTV1C, so that we can refer to it from `c`. It's OK if the vtable refers to the imported thunks, since the address of virtual methods isn't user visible.

Either that, or we need to make something like this change here, right?


Repository:
  rC Clang

https://reviews.llvm.org/D43184