llvm dev - Nov 2011 - [LLVMdev] LLVM 2.9 - JIT problem on Windows

> > Now, I may be wrong, but I was under the impression that a call to
> > InitializeNativeTarget was recommended, if not compulsory, so. why
> > commenting it out not only makes my LLVM code still work, but also
> > prevent my application from generating the above error.?!
> 
> My bet is that your code is writing through a stray pointer. By removing
the
> call to InitializeNativeTarget you are simply hiding your bug by running
the
> code within a context that turns its effects harmless.
> 
> OTOH, LLVM 2.9 may be the culprit. In any case, it is time for a assembler-
> level debug session :-) You can try using the Windows equivalent for
valgrind
> and pray that it catches the problem. Or use valgrind on Linux.
Thanks, I thought it might be an issue with a stray pointer. It's just that
I assumed that since 'my' LLVM code is a shameless copy/paste of one of
LLVM's examples that it would be fine. Anyway, I am going to investigate
things further.

Alan

> > > Now, I may be wrong, but I was under the impression that a call
to
> > > InitializeNativeTarget was recommended, if not compulsory, so.
why
> > > commenting it out not only makes my LLVM code still work, but
also
> > > prevent my application from generating the above error.?!
> >
> > My bet is that your code is writing through a stray pointer. By
> > removing the call to InitializeNativeTarget you are simply hiding your
> > bug by running the code within a context that turns its effects
harmless.
> >
> > OTOH, LLVM 2.9 may be the culprit. In any case, it is time for a
> > assembler- level debug session :-) You can try using the Windows
> > equivalent for valgrind and pray that it catches the problem. Or use
valgrind
> on Linux.
> 
> Thanks, I thought it might be an issue with a stray pointer. It's just
that I
> assumed that since 'my' LLVM code is a shameless copy/paste of one
of
> LLVM's examples that it would be fine. Anyway, I am going to
investigate
> things further.
Hmm... I have just spent some time going through various Valgrind reports,
but to no avail. Nothing wrong with 'my' LLVM code... Frustrating!

Alan

> > > My bet is that your code is writing through a stray pointer. By
> > > removing the call to InitializeNativeTarget you are simply hiding
> > > your bug by running the code within a context that turns its
effects
> harmless.
> > >
> > > OTOH, LLVM 2.9 may be the culprit. In any case, it is time for a
> > > assembler- level debug session :-) You can try using the Windows
> > > equivalent for valgrind and pray that it catches the problem. Or
use
> valgrind
> > on Linux.
> >
> > Thanks, I thought it might be an issue with a stray pointer. It's
just
> that I
> > assumed that since 'my' LLVM code is a shameless copy/paste of
one of
> > LLVM's examples that it would be fine. Anyway, I am going to
> > investigate things further.
> 
> Hmm... I have just spent some time going through various Valgrind reports,
> but to no avail. Nothing wrong with 'my' LLVM code... Frustrating!
FWIW, I have simplified 'my' LLVM code to just:

    llvm::InitializeNativeTarget();
    llvm::LLVMContext context;

    llvm::Module *module = new llvm::Module("test", context);
    llvm::Function *fooFunc
llvm::cast<llvm::Function>(module->getOrInsertFunction("foo",
 
llvm::Type::getVoidTy(context),
 
(llvm::Type *) 0));
    llvm::BasicBlock *basicBlock = llvm::BasicBlock::Create(context,
"entryBlock", fooFunc);

    llvm::ReturnInst::Create(context, basicBlock);

    llvm::ExecutionEngine *executionEngine llvm::EngineBuilder(module).create();

    llvm::outs() << "We just constructed this LLVM module:\n\n"
<< *module;
    llvm::outs() << "\n\nRunning foo...\n";
    llvm::outs().flush();

    std::vector<llvm::GenericValue> noargs;
    executionEngine->runFunction(fooFunc, noargs);
    executionEngine->freeMachineCodeForFunction(fooFunc);

    delete executionEngine;

    llvm::llvm_shutdown();

and I am still getting the same problem. I have then copied/pasted some
other LLVM code (from the LLVM distribution) and... yes, still the same
problem!

Just in case, I have built LLVM using MinGW/MSYS + Python on Windows 7 and
with:

    ./configure --disable-docs --enable-shared --enable-targets=host

Could it be that something is wrong with my MinGW shared library?

Alan