On Tue, Jul 26, 2011 at 11:01 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> On Jul 26, 2011, at 8:11 AM, Talin wrote:
>
>
>> If that's true, then it means that we're back to the case where
every type
>> has to be fully defined down to the leaf level.
>>
>>
>> I'm not sure what you mean. LLVM is perfectly fine with opaque
structs so
>> long as you don't "deference" them, GEP into them, need
their size, etc.
>>
>
> Let me try with another example: Let's say Module A and Module B both
> import class Exception. Class Exception has a "message" field
which is a
> pointer to type String. Now, let's say Module A dereferences the
> Exception.message field by printing the message. The compiler sees this
> dereference, and automatically loads the String module. Type String is
added
> to Module A as a fully-resolved struct type.
>
> In Module B, on the other hand, there is no dereference of the message
> field. So the compiler includes the definition of Exception, but the
> definition of String is opaque, because no code in Module B ever referred
to
> any of the fields of class String. In fact the compiler never even loaded
> the definition of String because it wasn't needed.
>
> Now we attempt to link together a bunch of modules including A and B. The
> linker sees that there are two types named "Exception" and
renamed one of
> them. It also sees that there are two types named "String" and
renames one
> of those as well. At this point, the linker fails because of a type
> mismatch. At least, this is the behavior that I am seeing.
>
>
> What do you mean "the linker fails"? Type mismatches should not
cause the
> linker to fail. In any case, this example should link, please provide a
> minimal example of two .ll files that repros what you're seeing with
> llvm-link. Thanks,
>
> It's llvm-ld that asserts here:
Assertion failed: (N < NumContainedTys && "Element number out of
range!"),
function getElementType, file
/Users/talin/Projects/llvm/include/llvm/DerivedTypes.h, line 268.
5 0x0000000100158f27 in llvm::StructType::getElementType (this=0x10180f310,
N=0) at DerivedTypes.h:268
#6 0x00000001001b8b54 in llvm::BitcodeReader::ParseConstants
(this=0x101813800) at
/Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1256
#7 0x00000001001be481 in llvm::BitcodeReader::ParseModule
(this=0x101813800) at
/Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1578
#8 0x00000001001bf8fb in llvm::BitcodeReader::ParseBitcodeInto
(this=0x101813800, M=0x101605dd0) at
/Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1848
#9 0x00000001001bf9ea in llvm::getLazyBitcodeModule (Buffer=0x10181b800,
Context=@0x101600290, ErrMsg=0x7fff5fbfc8f0) at
/Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:2776
#10 0x00000001001bfa7b in llvm::ParseBitcodeFile (Buffer=0x10181b800,
Context=@0x101600290, ErrMsg=0x7fff5fbfc8f0) at
/Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:2792
#11 0x000000010006cf52 in llvm::Linker::LoadObject (this=0x7fff5fbfcd50,
FN=@0x101801a28) at /Users/talin/Projects/llvm/lib/Linker/Linker.cpp:107
#12 0x000000010006494e in llvm::Linker::LinkInFile (this=0x7fff5fbfcd50,
File=@0x101801a28, is_native=@0x7fff5fbfcb7f) at
/Users/talin/Projects/llvm/lib/Linker/LinkItems.cpp:199
#13 0x0000000100064c5e in llvm::Linker::LinkInFiles (this=0x7fff5fbfcd50,
Files=@0x7fff5fbfce30) at
/Users/talin/Projects/llvm/lib/Linker/LinkItems.cpp:238
#14 0x0000000100007c1f in main (argc=130, argv=0x7fff5fbfd1f0,
envp=0x7fff5fbfd608) at
/Users/talin/Projects/llvm/tools/llvm-ld/llvm-ld.cpp:582
I'll get you a reproducible test case in the next day or so.
> -Chris
>
--
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110727/f1343013/attachment.html>