mstorsjo added a comment.

In https://reviews.llvm.org/D43184#1009355, @rnk wrote:

> 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.


Fair enough. And I managed to work around it for now, and for a future release, 
they're planning on redefining this struct for windows, to avoid this issue 
altogether. (On the other hand, I guess the C++ standard doesn't concern itself 
about dllimport at all, so on the standard level, there's nothing that would 
say that this even is a partially initialized object. Not sure in which way it 
would affect an argument anyway.)

> 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?

Ok, I see. For this case I guess it should be mostly straightforward to just 
tweak a few decisions in ItaniumCXXABI to choose emitting new vtables as 
linkonce_odr - that would sound like a nice solution.

But for the case of `__cxxabiv1::__class_type_info`, there's no declaration 
visible in scope at all, and the actual contents of the vtable of this class 
(and the other similar classes) doesn't seem to be defined in the ABI (it seems 
to differ significantly between libc++abi and libsupc++). Or do you have any 
idea of how to work around that as well? We could emit an empty local vtable 
and try to initialize that at runtime by copying from the dllimported real 
vtable - but I guess we don't even know the size of it, when its members are 
defined by the c++abi implementation.


Repository:
  rC Clang

https://reviews.llvm.org/D43184



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to