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

Hi, everyone. I've run into a strange problem generating code that contains
the `dispatch_object_t` type.

The problem happens when a program does these steps (all with the global
LLVMContext):

	1. Loads a module (otherModule) that uses `dispatch_object_t`. 
	2. Generates code that calls `dispatch_release`, which takes a
`dispatch_object_t` argument, into a module (mainModule).
	3. Links otherModule into mainModule. 
	4. Generates more code that calls `dispatch_release`.  

In Step 4, the following failure occurs on the `CallInst::Create` call for
`dispatch_release`:

Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) ==
Args[i]->getType()) && "Calling a function with a bad
signature!"), function init, file Instructions.cpp, line 274.

This happens because the StructType returned by
`mod->getTypeByName("union.dispatch_object_t")` is different
between Step 2 and Step 4. According to `Type::dump()`, it is:

	Step 2: 	%union.dispatch_object_t = type { %struct.dispatch_object_s* }
	Step 4: 	%union.dispatch_object_t = type { %struct.dispatch_object_s.1* }

Code that reproduces the problem is at http://pastebin.com/pxveBUJa and
http://pastebin.com/GDb9n9xA.

A workaround is to call `StructType::create(mod->getContext(),
"union.dispatch_object_t")` before doing Step 1.

This sounds like what Chris was talking about in his blog post on the LLVM 3.0
type system, "The Linker 'links' types and retypes IR
objects". Except that I would have expected the Linker to recognize that
the `dispatch_object_t` type in the loaded module and the generated code are the
same. Am I doing something wrong, or is this a bug in LLVM? (I have LLVM 3.1,
Mac OS X 10.6.)

Thanks for your time. 

---
Jaymie Strecker
jstrecker at kosada.com

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

Hi Jaymie,

...
 > Step 2: %union.dispatch_object_t = type { %struct.dispatch_object_s*
}
> Step 4: %union.dispatch_object_t = type { %struct.dispatch_object_s.1* }
>
> Code that reproduces the problem is at http://pastebin.com/pxveBUJa and
> http://pastebin.com/GDb9n9xA.
>
> A workaround is to call
> `StructType::create(mod->getContext(),
"union.dispatch_object_t")` before doing
> Step 1.
>
> This sounds like what Chris was talking about in his blog post on the LLVM
3.0
> type system
<http://blog.llvm.org/2011/11/llvm-30-type-system-rewrite.html>,
> "The Linker 'links' types and retypes IR objects".
exactly, this is where it is coming from.

  Except that I would have
> expected the Linker to recognize that the `dispatch_object_t` type in the
loaded
> module and the generated code are the same. Am I doing something wrong, or
is
> this a bug in LLVM? (I have LLVM 3.1, Mac OS X 10.6.)
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?), but I
think there were also some bugs in this area that were fixed in 3.2.

Ciao, Duncan.

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>