[cfe-commits] r116186 - in /cfe/trunk: lib/CodeGen/CGRTTI.cpp lib/CodeGen/CGVTables.cpp lib/CodeGen/CGVTables.h test/CodeGenCXX/vtable-linkage.cpp

[Douglas Gregor]

On Oct 11, 2010, at 2:18 PM, Argyrios Kyrtzidis wrote:

> On 11 Oct 2010, at 14:15, Douglas Gregor wrote:
> 
>> 
>> On Oct 11, 2010, at 2:03 PM, Argyrios Kyrtzidis wrote:
>> 
>>> On 11 Oct 2010, at 13:42, Douglas Gregor wrote:
>>> 
>>>> 
>>>> On Oct 11, 2010, at 11:22 AM, Argyrios Kyrtzidis wrote:
>>>> 
>>>>> $ cat t.cpp
>>>>> template <typename T>
>>>>> struct S {
>>>>> 	virtual void m();
>>>>> };
>>>>> 
>>>>> void f() {
>>>>> 	S<int> *s = new S<int>;
>>>>> }
>>>>> 
>>>>> $ clang -S -emit-llvm t.cpp -o -
>>>>> [...]
>>>>> @_ZTV1SIiE = external constant [3 x i8*]
>>>>> [...]
>>>>> 
>>>>> $ llvm-gcc -S -emit-llvm t.cpp -o -
>>>>> [...]
>>>>> %struct.__class_type_info_pseudo = type { %struct.__type_info_pseudo }
>>>>> %struct.__type_info_pseudo = type { i8*, i8* }
>>>>> 
>>>>> @_ZTV1SIiE = weak_odr constant [3 x i32 (...)*] [i32 (...)* null, i32 (...)* bitcast (%struct.__class_type_info_pseudo* @_ZTI1SIiE to i32 (...)*), i32 (...)* bitcast (void (%"struct.S<int>"*)* @_ZN1SIiE1mEv to i32 (...)*)], align 16 ; <[3 x i32 (...)*]*> [#uses=1]
>>>>> @_ZTI1SIiE = weak_odr constant %struct.__class_type_info_pseudo { %struct.__type_info_pseudo { i8* inttoptr (i64 add (i64 ptrtoint ([0 x i32 (...)*]* @_ZTVN10__cxxabiv117__class_type_infoE to i64), i64 16) to i8*), i8* getelementptr inbounds ([6 x i8]* @_ZTS1SIiE, i64 0, i64 0) } }, align 16 ; <%struct.__class_type_info_pseudo*> [#uses=1]
>>>>> @_ZTVN10__cxxabiv117__class_type_infoE = external constant [0 x i32 (...)*] ; <[0 x i32 (...)*]*> [#uses=1]
>>>>> @_ZTS1SIiE = weak_odr constant [6 x i8] c"1SIiE\00" ; <[6 x i8]*> [#uses=2]
>>>>> [..]
>>>>> 
>>>>> 
>>>>> This resulted in an unresolved symbol linker error in Qt.
>>>> 
>>>> This should only happen if the method S<int>::m is not instantiated anywhere else in Qt. Is that really the case?
>>> 
>>> To be more clear, when using clang, the specific executable being linked fails with linker error because the VTable symbol is not defined in the object files being linked.
>>> With gcc, the VTable is emitted (as in the test case I posted) and the key function is resolved dynamically when the executable is run.
>> 
>> But where does the body of the key function come from? Some other library that's loaded dynamically?
> 
> Yes, exactly.
> 
>> 
>> More importantly, did the key function get instantiated somewhere and we failed to emit the vtables + RTTI at that point?
> 
> No, it gets instantiated at a library outside of the executable.


That is absolutely disgusting :(

Alright, we're stuck with this approach, then. Thanks for fixing this.

	- Doug