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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
