search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.54k stars 11.8k forks source link

MCJIT EH fails when more than one instance used during program #21327

Open llvmbot opened 10 years ago

llvmbot commented 10 years ago
Bugzilla Link 20953
Version trunk
OS Windows NT
Reporter LLVM Bugzilla Contributor
CC @atamazov

Extended Description

When MCJIT is executed during a program, if MCJIT is executed again, the EH fails. This is targetting i686-pc-windows-itanium-elf, linking in dynamically libstdc++ 4.6.3 with mingw-w64-dw2. I'm running Windows 7 x64, but the host is x86 MSVC 2013 ABI and not Itanium.

Specifically, in my current frontend, the JIT is used to evaluate certain constructs during compilation time, in the sample case a simple function returning a constant integer, and then invoked again later to run the resulting program. The resulting program doesn't appear to have correct EH mechanisms- when __cxa_throw is invoked, the process terminates as if there were no handlers, even if a catch-all landingpad is used.

If a fast-path for a constant integer is included that avoids invoking MCJIT, the resulting program executes correctly. I've verified that the IR generated for the fast path and the MCJIT path is identical.

llvmbot commented 10 years ago

I'm almost sure Version 3.5 already uses the MinGW 4.7 (and later) ABI.

It's probably unrelated to this EH problem, but worth re-checking with newer MinGW. Anyhow this ABI change may cause troubles later on.

llvmbot commented 10 years ago

I'm actually using 3.5 release. There's just no version tag for it. Also, that specific ABI change has nothing to do with EH, AFAIK.

llvmbot commented 10 years ago

Note there was an incompatible ABI change form MingW-w64 from 4.6 to 4.7 and current trunk is compatible with the later.

It may not be the issue for a function returning integer.