Invalid bitcode signature

I'm trying to link two modules together using the C++ API, one that's a sort
of library module and one that's being generated from the source language.

If I have something like this:

OwningPtr<MemoryBuffer> owning_ptr;
if (MemoryBuffer::getFile(StringRef("../hello.bc"), owning_ptr))
    std::cout << "error opening file" << std::endl;

Module* Lib = ParseBitcodeFile(owning_ptr.get(), context, &error);
  
if (!Lib)
    std::cout << error << std::endl;

When I run this (either on a bitcode file generated by llvm-gcc or by
createBitcodeWriterPass()) I get an error telling me: "invalid bitcode
signature".

I'm not sure where this error's coming from. Any help would be appreciated.

The error is coming from the bit-code reader. Make sure that you generated the file with '-emit-llvm' (i.e., it's not an object file) and that it's the binary version of the bit-code file, not the text version.

And, llvm-gcc? really? :slight_smile:

-bw

Bill Wendling-3 wrote:

The error is coming from the bit-code reader. Make sure that you generated
the file with '-emit-llvm' (i.e., it's not an object file) and that it's
the binary version of the bit-code file, not the text version.

And, llvm-gcc? really? :slight_smile:

Is there no way that the API can generate valid bitcode?

And no, not really llvm-gcc, I'm not sure why I said that, haha :slight_smile:

Hi Fraser,

Sorry, I was being an idiot and was trying to link the wrong file type. Sigh.

Now I have a problem where I merge two modules each containing the same
struct, one opaque and one defined, and it's not merging the two
consistently. I have two, let's say

%"StructA" = type opaque
%"StructB" = type opaque

in one module, and in the other:

%"StructA" = type { i8 }
%"StructB" = type { [0 x i8] }

and when I link the two modules, only one is correctly defined:

%"StructA" = { i8 }
%"StructB" = type opaque
%"StructB.0" = { [0 x i8] }

I know it's not technically 'on-topic' for this thread, but just in case you
had any ideas as to why this is happening.

Cheers/

Duncan Sands wrote:

Sorry, I was being an idiot and was trying to link the wrong file type. Sigh.

Now I have a problem where I merge two modules each containing the same
struct, one opaque and one defined, and it's not merging the two
consistently. I have two, let's say

%"StructA" = type opaque
%"StructB" = type opaque

in one module, and in the other:

%"StructA" = type { i8 }
%"StructB" = type { [0 x i8] }

and when I link the two modules, only one is correctly defined:

%"StructA" = { i8 }
%"StructB" = type opaque
%"StructB.0" = { [0 x i8] }

I know it's not technically 'on-topic' for this thread, but just in case you
had any ideas as to why this is happening.

Are you using mainline or LLVM 3.0? The behavior in this area has changed since 3.0 was released (and it should now do what you want).

-Chris

Ah, updating to LLVM 3.0 has worked, thanks!

Once again, this is sorta off topic (I don't want to unnecessarily start a
new thread), but I've noticed that my program segmentation faults when I try
and use a GEP on a struct that is opaque in a module, but will be resolved
when linked to another module later, like this:

if (reg_pt_st->isOpaque())
  std::cout << "opaque" << std::endl;

ConstantInt* index = ConstantInt::get(mod->getContext(), APInt(32,
StringRef("0"), 10));
std::vector<llvm::Value*> indices;
indices.push_back(index); indices.push_back(index);
        
Value* gep_ptr = builder->CreateGEP(reg, indices);

Here, 'reg' is a pointer to a struct, and so 'reg_pt_st' is the cast from
'reg' to pointer to struct.

Is this possible? What am I supposed to do here? Would using a different
LLVMContext (for instance the one that defines the struct) solve it? That
just came to me now.

Cheers,
Fraser

Chris Lattner-2 wrote:

Oh, and upgrading hasn't actually fully worked, I'm still getting cases where
it's not merging the two structs from each module properly.

This, coupled with my issue of segfaulting when accessing a struct field
that I know will exist once modules are linked, is causing me a bit of a
headache.

How do other people get around this?

Thanks,
Fraser

Chris Lattner-2 wrote:

Hi Fraser,

Oh, and upgrading hasn't actually fully worked, I'm still getting cases where
it's not merging the two structs from each module properly.

that may depend on how you define "properly"! :slight_smile:

This, coupled with my issue of segfaulting when accessing a struct field
that I know will exist once modules are linked, is causing me a bit of a
headache.

How do other people get around this?

First off, they configure LLVM with --enable-assertions so that they get
helpful messages rather than segmentation faults! Secondly, if you know
what the final type is, or at least that it will have a certain field at
a certain position, why not declare an appropriate type T in your module,
one which has such a field in that position, and bitcast your opaque* to
a T* before using GEP. Alternatively, bitcast your opaque* to an i8* and
do a GEP that offsets the pointer by the offset your field will be at.
This is assuming that you know in advance what the offset of your field is.

Ciao, Duncan.