llvm dev - Dec 2012 - [LLVMdev] StructType for dispatch_object_t changed by Linker

Duncan, thanks for your reply. 
> Probably the types are not defined precisely the same in each module (maybe
you
> could send the exact definitions in each module to the mailing list?), 

In the module loaded in Step 1 (otherModule): 

%struct.dispatch_group_s = type opaque
%union.dispatch_object_t = type { %struct.dispatch_object_s* }
%struct.dispatch_object_s = type opaque

In the module generated in Step 2 (mainModule): 

%struct.dispatch_group_s = type {}
%union.dispatch_object_t = type { %struct.dispatch_object_s* }
%struct.dispatch_object_s = type {}

(The LLVM API calls to generate mainModule were generated by calling `llc
-march=cpp` on otherModule.)
> but I
> think there were also some bugs in this area that were fixed in 3.2.
Great, I'll also test on 3.2 when I get a chance. Thanks. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121214/af69b251/attachment.html>

Le 14 déc. 2012 à 17:08, Jaymie Strecker <jstrecker at kosada.com> a écrit
:
> Duncan, thanks for your reply. 
> 
>> Probably the types are not defined precisely the same in each module
(maybe you
>> could send the exact definitions in each module to the mailing list?), 
> 
> 
> In the module loaded in Step 1 (otherModule): 
> 
> %struct.dispatch_group_s = type opaque
> %union.dispatch_object_t = type { %struct.dispatch_object_s* }
> %struct.dispatch_object_s = type opaque
> 
> In the module generated in Step 2 (mainModule): 
> 
> %struct.dispatch_group_s = type {}
> %union.dispatch_object_t = type { %struct.dispatch_object_s* }
> %struct.dispatch_object_s = type {}
> 
> (The LLVM API calls to generate mainModule were generated by calling `llc
-march=cpp` on otherModule.)
> 
Is there any chance one module was compiled in C mode and the other one in C++
mode ?

The dispatch_object declarations are not the same for both languages:

#if defined(__cplusplus)
/*
 * Dispatch objects are NOT C++ objects. Nevertheless, we can at least keep C++
 * aware of type compatibility.
 */
typedef struct dispatch_object_s {
private:
	dispatch_object_s();
	~dispatch_object_s();
	dispatch_object_s(const dispatch_object_s &);
	void operator=(const dispatch_object_s &);
} *dispatch_object_t;

>> but I
>> think there were also some bugs in this area that were fixed in 3.2.
> 
> Great, I'll also test on 3.2 when I get a chance. Thanks. 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-- Jean-Daniel




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121214/8b8b8111/attachment.html>

Jean-Daniel, 
>>> Probably the types are not defined precisely the same in each
module (maybe you
>>> could send the exact definitions in each module to the mailing
list?),
>> 
>> 
>> In the module loaded in Step 1 (otherModule): 
>> 
>> %struct.dispatch_group_s = type opaque
>> %union.dispatch_object_t = type { %struct.dispatch_object_s* }
>> %struct.dispatch_object_s = type opaque
>> 
>> In the module generated in Step 2 (mainModule): 
>> 
>> %struct.dispatch_group_s = type {}
>> %union.dispatch_object_t = type { %struct.dispatch_object_s* }
>> %struct.dispatch_object_s = type {}
>> 
>> (The LLVM API calls to generate mainModule were generated by calling
`llc -march=cpp` on otherModule.)
>> 
> 
> Is there any chance one module was compiled in C mode and the other one in
C++ mode ?
> 
> The dispatch_object declarations are not the same for both languages:
Good question, but I don't think that's it. When otherModule is compiled
as C++ code, the types are completely different:

%struct.dispatch_group_s = type { i8 }
%struct.dispatch_object_s = type { i8 }

-Jaymie

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121214/587d9290/attachment.html>