LLVM 2.9 - JIT problem on Windows

Project Infrastructure LLVM Dev List Archives
1

Hi,

I have built a shared version of LLVM which I am now able to test in my Qt-based application. It all works fine on Windows, Linux and Mac OS X, except that whenever I exit my Qt-based application on Windows (everything is fine on Linux and Mac OS X), I get a message that reads that “this application has requested the Runtime to terminate it in an unusual way”.

‘My’ current LLVM code (see https://github.com/opencor/opencor/blob/master/src/plugins/simulation/CoreSimulation/src/coresimulationplugin.cpp) is a shameless copy/paste of the HowToUseJIT example (in the examples folder). However, if I comment out line #67 of my code (i.e. llvm::InitializeNativeTarget();), then I don’t get the aforementioned error and my LLVM code still works fine.

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…?!

Cheers, Alan.

2

"Alan Garny" <alan.garny@dpag.ox.ac.uk> writes:

I have built a shared version of LLVM which I am now able to test in my
Qt-based application. It all works fine on Windows, Linux and Mac OS X,
except that whenever I exit my Qt-based application on Windows (everything
is fine on Linux and Mac OS X), I get a message that reads that "this
application has requested the Runtime to terminate it in an unusual way".

'My' current LLVM code (see
https://github.com/opencor/opencor/blob/master/src/plugins/simulation/CoreSi
mulation/src/coresimulationplugin.cpp) is a shameless copy/paste of the
HowToUseJIT example (in the examples folder). However, if I comment out line
#67 of my code (i.e. llvm::InitializeNativeTarget();), then I don't get the
aforementioned error and my LLVM code still works fine.

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 :slight_smile: You can try using the Windows
equivalent for valgrind and pray that it catches the problem. Or use
valgrind on Linux.

3

> 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 :slight_smile: 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

4

> > 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 :slight_smile: 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

5

> > 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 :slight_smile: 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

6

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

Are you seeing the same problem with static build?

7

> Could it be that something is wrong with my MinGW shared library?
Are you seeing the same problem with static build?

Sorry, but I haven't tried with a static build, not least because I am not sure how that could work for my particular Qt-based project. Indeed, I need LLVM to work as a plugin within my application (and therefore be loaded only when required by other plugins that rely on LLVM). Sure, I could have those LLVM-based plugins to have LLVM statically linked into them, but that wouldn't be neat.

Alan