[LLVMdev] StructType for dispatch_object_t changed by Linker
Jaymie Strecker
jstrecker at kosada.com
Thu Dec 13 18:24:11 PST 2012
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>
More information about the llvm-dev
mailing list