similar to: [LLVMdev] VMKit assertion failure

Hi Konrad, Yes, there has been an incompatibility change recently between LLVM and VMKit. Please use revision 100087 of LLVM until I find a workaround. Also, running on Snow Leopard is untested (VMKit does not have support for GC on 64bits), but should work without a GC. You can also try to compile on 32bits. Cheers, Nicolas On Fri, Apr 2, 2010 at 3:08 PM, Konrad Hinsen <konrad.hinsen at

Hello, I am using Ubuntu 11.10 64-bit. Following the instructions on the VMKit website I grabbed llvm, clang, and vmkit via svn (and GNU Classpath via the link of the page). Compilation of llvm, clang and classpath went fine. I had problems compiling vmkit, which seem to be related to a TargetOptions being required as a parameter when creating a TargetMachine in LLVM. This led to a couple other

Hi all, I tried the step of the Getting Started page (http://vmkit.llvm.org/get_started.html) on Linux/x64 but I had no luck. I could build them. But when I tried to execute J3, it shows like follows, >> j3: JavaRuntimeJIT.cpp:367: void* j3StartJNI(uint32*, uint32**, mvm::KnownFrame*): Assertion `th->getLastSP() == th->lastKnownFrame->currentFP' failed. Does anybody know if

Hi Nicolas, > Did you compile vmkit with llvm-gcc or gcc? Did you make sure the > path to GNU Classpath is correct in your configure command? I let the configure script of VMKit do its work and it decided to use gcc, the gcc 4.0.1 that is part of Apple's XCode distribution for MacOS 10.5. There is no llvm-gcc anywhere on my machine. Should I have one? I did install llvm without

Hi Nicolas, >> How would I run VMKit without GC? > > VMKit just falls back to malloc when it detects that the machine is > 64bits. OK, I think I can handle that ;-) > Yes, running a 32bits virtualized system should work just fine. I first tried something else: compiling on an older Mac (10.5, 32 bit compilers) and copy the binary over to the 64-bit Mac. Of course I ran

Hi Konrad, Did you compile vmkit with llvm-gcc or gcc? Did you make sure the path to GNU Classpath is correct in your configure command? Also, you can now update to the latest revision. Cheers, Nicolas On Tue, Apr 6, 2010 at 6:15 PM, Konrad Hinsen <konrad.hinsen at fastmail.net>wrote: > Hi Nicolas, > > > How would I run VMKit without GC? >>> >> >> VMKit

On 11.04.2010, at 19:14, nicolas geoffray wrote: > On Sun, Apr 11, 2010 at 7:12 PM, Konrad Hinsen <konrad.hinsen at fastmail.net> wrote >> I am rather surprised that the size of a method should have an impact on stack usage, but then I haven't looked at all at how VMKit works yet. That's my next project :-) >> > It has no impact on VMKit. The impact is on LLVM

Hi Nicolas, > Yes, there has been an incompatibility change recently between LLVM and VMKit. Please use revision 100087 of LLVM until I find a workaround. OK, done. > Also, running on Snow Leopard is untested (VMKit does not have support for GC on 64bits), but should work without a GC. You can also try to compile on 32bits. How would I run VMKit without GC? Compiling for 32 bits is not

Hi Eli, I know the pass that fails, it is MachineCSE. It stack overflows because there are too many recursive calls to processBlock (line 362 of lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am sure there are other places where LLVM makes recursive calls. Or is recursion forbidden in LLVM, and explicitly stated to be so? Cheers, Nicolas On Tue, Apr 13, 2010 at 5:56

Hi Chanwit, What problems did you have for compiling the latest revision? Could you give me a log? Thanks, Nicolas On Thu, Jul 8, 2010 at 10:05 PM, Chanwit Kaewkasi <chanwit at gmail.com> wrote: > Thank you, Nicolas. > But I still have no luck compiling the latest revision. However, > vmkit-0.27 is compiled and running fine on my machine. > > Thanks, > > Chanwit >

On 10 Apr 2010, at 22:33, nicolas geoffray wrote: > OK, I know why you get that UnsatisfiedLinkError. You have made > symlinks of GNU Classpath libraries with the .so suffix. Since > you're on MacOS, you should do symlinks with the .dylib suffix (I > notice that I'm not saying that on the webpage, I'll fix that right > now). Thanks - that did it! All my tests

On Tue, Apr 13, 2010 at 2:29 AM, Konrad Hinsen <konrad.hinsen at fastmail.net> wrote: > On 11.04.2010, at 19:14, nicolas geoffray wrote: > >> On Sun, Apr 11, 2010 at 7:12 PM, Konrad Hinsen <konrad.hinsen at fastmail.net> wrote >>> I am rather surprised that the size of a method should have an impact on stack usage, but then I haven't looked at all at how VMKit

On Tue, Apr 13, 2010 at 9:33 AM, nicolas geoffray <nicolas.geoffray at gmail.com> wrote: > Hi Eli, > I know the pass that fails, it is MachineCSE. It stack overflows because > there are too many recursive calls to processBlock (line 362 of > lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am > sure there are other places where LLVM makes recursive

Hi, Just to comfirm that I have just clean built the current LLVM and VMKIT revisions and it failed too. The problem seems to be the same one (about escape analysis in LLVM). My configuration is Ubuntu 10.04 and GCC 4.4.3 on x86. Cheers, Chanwit Konrad Hinsen-2 wrote: > > On 6 Jul 2010, at 22:25, Zoe Wolk wrote: > >> If anyone is able to build vmkit and get it to run without

On Sun, Apr 11, 2010 at 7:12 PM, Konrad Hinsen <konrad.hinsen at fastmail.net>wrote > > I'm not sure what to do about that core__init function. I will try to >> create a bigger stack to see if that changes anything or if LLVM inifinite >> loops. >> > > I am rather surprised that the size of a method should have an impact on > stack usage, but then I

Hello Nicolas, Thank you for quick reply. Is LLVM revision 107641 a good one to build with latest VMKIT? Thanks, Chanwit On Thu, Jul 8, 2010 at 00:06, nicolas geoffray <nicolas.geoffray at gmail.com> wrote: > Hi all, > Yes, there was a change in the LLVM CallInst API, and I haven't updated > vmkit yet. It should be fixed real soon. > Cheers, > Nicolas > > On Wed,

On 7 Apr 2010, at 21:36, nicolas geoffray wrote: > Hmm, I am not getting that error message on my MacOS 10.5 machine > with that same gcc. Could you run j3 in gdb and get me a backtrace? Sure: (gdb) bt #0 0x950be44e in __semwait_signal () #1 0x950e93e6 in _pthread_cond_wait () #2 0x950e8dcd in pthread_cond_wait$UNIX2003 () #3 0x000be2d2 in mvm::Cond::wait (this=0x20527c4,

Latest version of vmkit should now build fine with latest llvm. Nicolas On Wed, Jul 7, 2010 at 11:02 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > The one that I have currently that works with vmkit is 107120. > > > On Wed, Jul 7, 2010 at 10:58 AM, Chanwit Kaewkasi <chanwit at gmail.com>wrote: > >> Hello Nicolas, >> >> Thank you for

Hi all, Yes, there was a change in the LLVM CallInst API, and I haven't updated vmkit yet. It should be fixed real soon. Cheers, Nicolas On Wed, Jul 7, 2010 at 9:50 AM, chanwit <chanwit at gmail.com> wrote: > > Hi, > > Just to comfirm that I have just clean built the current LLVM and VMKIT > revisions and it failed too. > The problem seems to be the same one (about

The one that I have currently that works with vmkit is 107120. On Wed, Jul 7, 2010 at 10:58 AM, Chanwit Kaewkasi <chanwit at gmail.com> wrote: > Hello Nicolas, > > Thank you for quick reply. > Is LLVM revision 107641 a good one to build with latest VMKIT? > > Thanks, > > Chanwit > > On Thu, Jul 8, 2010 at 00:06, nicolas geoffray > <nicolas.geoffray at