<p dir="ltr">Oups, sorry for the mistake, llcj (not llc:)) is not more maintained!</p>
<p dir="ltr">Gaël </p>
<div class="gmail_quote">Le 10 sept. 2014 00:27, "Gaël Thomas" <<a href="mailto:gael.thomas00@gmail.com">gael.thomas00@gmail.com</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brian,<br>
<br>
So, I confirm, llc is not more maintained. And using vmjc is probably<br>
the good starting point to translate Java bytecode into llvm bitcode.<br>
<br>
However, I think that your hack (changing the way VMKitGCPrinter.cpp<br>
resolves symbols) is probably not the good way to solve the initial<br>
problem. And maybe that your current problem is simply a consequence<br>
of the mangling problem. So, let's start with the first problem :)<br>
<br>
So, I answer in your previous mail. As it's the beginning of the year<br>
(I'm teaching), I haven't found any time to install vmkit and make the<br>
tests. But we will proceed step by step to understand the problem. In<br>
parallel, I'm also writing a documentation to describe the internals<br>
of VMKit, it will be useful for you and other people interested by the<br>
AOT.<br>
<br>
2014-09-02 18:13 GMT+02:00 Brian Faull <<a href="mailto:bfaull@cog-e.com">bfaull@cog-e.com</a>>:<br>
> Hi Gaël,<br>
><br>
> So as not to get too far into the "weeds" -- let's start with minimal configuration, then `vmjc` (.class -> .bc), then `llc` (.bc -> asm) to make sure I'm on the right path!<br>
><br>
> 1- CONFIGURATION<br>
> I can configure out of the box with no problem. But perhaps I need to configure differently.<br>
><br>
> I start with a clean checkout of the VMKit repository into /path/to/vmkit_test-clean . I'm on x86_64 using OpenJDK1.6 as follows:<br>
><br>
> ==========<br>
> /path/to/vmkit_test-clean<br>
> ./configure --with-llvm-config-path=/path/to/llvm33/bin/llvm-config --with-classpath-impl=openjdk --with-openjdk-path=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64<br>
> ==========<br>
><br>
> I have PATH set to provide `javac` as /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/javac and LD_LIBRARY_PATH to include /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64 and ...amd64/server .<br>
><br>
> This `configure` command works. I see two WARNINGs during this build, as a result of<br>
> ==========<br>
> [vmkit ./mmtk/java]: Linking module 'FinalMMTk.bc'<br>
> /path/to/llvm33/bin/llvm-link /path/to/vmkit_test-clean/mmtk/java/Release+Asserts/mmtk-vmkit.bc /path/to/vmkit_test-clean/Release+Asserts/lib/MMTKAlloc.bc /path/to/vmkit_test-clean/Release+Asserts/lib/MMTKRuntime.bc -o /path/to/vmkit_test-clean/mmtk/java/Release+Asserts/FinalMMTk.bc<br>
> WARNING: Linking two modules of different data layouts!<br>
> WARNING: Linking two modules of different data layouts!<br>
> ==========<br>
> I'm not sure if that matters.<br>
<br>
It does not matter :)<br>
<br>
<br>
><br>
> I have also tried OpenJDK 1.7 and GNU Classpath, and I think I see the same results, but perhaps I didn't reset environment variables or something.<br>
><br>
> Some fundamental questions: basically, how do *YOU* configure VMKit?<br>
> -> Which version of Java do you recommend? 1.5, 1.6, 1.7...? Is there any benefit of using one or another, or any restrictions?<br>
> -> Do you recommend OpenJDK or GNU Classpath? Is there any benefit of using one or the other, or any tradeoff?<br>
<br>
You only have to use openjdk (gnu classpath is not more maintained as<br>
the project is also retired:)). We have a bug with the new versions of<br>
openjdk, and we are using the 6u23. I don't know if all the previous<br>
versions will be ok. So, I suggest using this version.<br>
<br>
<br>
><br>
> 2- COMPILATION: `vmjc` and `llc` to for Java class to native assembly.<br>
> I do the following, with the same OpenJDK 1.6.0 `javac` command:<br>
><br>
> ==========<br>
> cd /path/to/vmkit_test-clean/tools/trainer<br>
> javac HelloWorld.java<br>
> ../../Release+Asserts/bin/vmjc -print-aot-stats HelloWorld.class<br>
> /path/to/llvm33/bin/llc -load=../../Release+Asserts/lib/static-gc-printer.so HelloWorld.class.bc<br>
> ==========<br>
><br>
> The `javac` command succeeds, and produces Java classfile HelloWorld.class. `java HelloWorld` outputs "Hello World".<br>
> The `vmjc` command succeeds, and produces LLVM bitcode HelloWorld.class.bc. `/path/to/llvm33/bin/llvm-nm HelloWorld.class.bc` shows reasonable symbols from that bitcode.<br>
> The `llc` command fails exactly the same as Dave Brazdil reported on 08 Mar; <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-March/070995.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-March/070995.html</a> .<br>
> => It seems that I need to point to that shared-object using -load=../../Release+Asserts/lib/static-gc-printer.so . I found this in a previous post to the LLVM list. Is this correct?<br>
<br>
Yes, it's mandatory.<br>
<br>
> => The output I see is as follows:<br>
> ==========<br>
> llc: VmkitGCPrinter.cpp:268: llvm::Constant *FindMetadata(const llvm::Function &): Assertion `0 && "Should have found a JavaMethod"' failed.<br>
> 0 llc 0x000000000154d5ee llvm::sys::PrintStackTrace(_IO_FILE*) + 46<br>
> 1 llc 0x000000000154d8ab<br>
> 2 llc 0x000000000154db1e<br>
> 3 libpthread.so.0 0x0000003f31a0f710<br>
> 4 libc.so.6 0x0000003ee9232925 gsignal + 53<br>
> 5 libc.so.6 0x0000003ee9234105 abort + 373<br>
> 6 libc.so.6 0x0000003ee922ba4e<br>
> 7 libc.so.6 0x0000003ee922bb10 __assert_perror_fail + 0<br>
> 8 static-gc-printer.so 0x00007febfc02b135 FindMetadata(llvm::Function const&) + 3813<br>
> 9 static-gc-printer.so 0x00007febfc02b892<br>
> 10 llc 0x0000000000e620a5 llvm::AsmPrinter::doFinalization(llvm::Module&) + 2597<br>
> 11 llc 0x00000000014bf0dc llvm::FPPassManager::doFinalization(llvm::Module&) + 92<br>
> 12 llc 0x00000000014bf58e llvm::MPPassManager::runOnModule(llvm::Module&) + 1134<br>
> 13 llc 0x00000000014bfb4e llvm::PassManagerImpl::run(llvm::Module&) + 302<br>
> 14 llc 0x00000000014bfda1 llvm::PassManager::run(llvm::Module&) + 33<br>
> 15 llc 0x00000000005ca548<br>
> 16 llc 0x00000000005c9242 main + 226<br>
> 17 libc.so.6 0x0000003ee921ed1d __libc_start_main + 253<br>
> 18 llc 0x00000000005c8f49<br>
> Stack dump:<br>
> 0. Program arguments: /path/to/llvm33/bin/llc -load=../../Release+Asserts/lib/static-gc-printer.so HelloWorld.class.bc<br>
> Aborted (core dumped)<br>
> ==========<br>
> => Do you see something similar? Or what could be the configuration difference?<br>
><br>
> I fixed this situation by modifying the sources backing static-gc-printer.so, as shown below.<br>
><br>
> Are we on the right path? Is this a good start?<br>
<br>
It's a very good start :) But your hack is not the good solution<br>
because you should return from FindMetaData at the line 229 (you<br>
should not reach the test at line 239).<br>
<br>
So, can you try this compilation scheme (without your hack in<br>
StaticGCPrinter.cpp:))?<br>
<br>
vmjc -print-aot-stats HelloWorld.class<br>
opt -load=../../Release+Asserts/lib/static-gc-pass.so -StaticGCPass<br>
HelloWorld.class.bc -o HelloWorld.class.gc.bc<br>
llc -load=../../Release+Asserts/lib/static-gc-printer.so HelloWorld.class.gc.bc<br>
<br>
If it does not change anything, can you send me the<br>
HelloWorld.class.bc file? I will quickly see if everything is ok for<br>
the GC and where is the problem.<br>
<br>
See you,<br>
Gaël<br>
<br>
><br>
> Thank you again for your help. I really appreciate it.<br>
> =brian<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
2014-09-09 21:51 GMT+02:00 Brian Faull <<a href="mailto:bfaull@cog-e.com">bfaull@cog-e.com</a>>:<br>
> Hello again Gaël, (et al)<br>
><br>
> More on rekindling work on VMKit! Thank you for your interactions thus far on- and off-list.<br>
><br>
> As you suggested in your VMKit-retirement email (to which I'm attempting to respond), I'm interested in producing a Java-to-LLVM compiler out of VMKit. I'd like to take you up on your offer to help understand the architecture. If I can get the a Java-to-LLVM compiler working for my purposes, I'll be happy to maintain at least this part of the VMKit project.<br>
><br>
> To that end, I have exactly one fundamental question to start:<br>
><br>
><br>
> How do you suggest to perform Java-to-LLVM compilation using VMKit?<br>
><br>
><br>
> Here are my thoughts on this:<br>
><br>
> It looks like the `llcj` tool (VMKit/tools/llcj/llcj.cpp) was meant for this; it declares itself as "Java to native compiler" but it appears that it hasn't been maintained (e.g., deprecated interfaces, no-longer-existent command-line options and libraries). `llcj` is described in Appendix A of Geoffray's thesis, <a href="http://pagesperso-systeme.lip6.fr/Nicolas.Geoffray/these-geoffray.pdf" target="_blank">http://pagesperso-systeme.lip6.fr/Nicolas.Geoffray/these-geoffray.pdf</a> linked from the VMKit site.<br>
><br>
> `llcj` attempts the following to translate Java to native:<br>
> * vmjc (Java .class => LLVM bitcode .bc)<br>
> * opt (LLVM bitcode optimizer)<br>
> * llc (LLVM bitcode => target assembly .s)<br>
> * gcc (assemble and link)<br>
><br>
> Is that "The Right Way"?<br>
><br>
> After some time hacking various changes, I can use basically that method to compile VMKit/tools/trainer/HelloWorld.java into a linked executable (but it barfs at runtime and I can't fix it).<br>
><br>
> I'm doing roughly the following, on x86_64, using LLVM3.3, OpenJDK 1.6.0 build 30, a debug build of VMKit (required small build-hacks, which I could describe on request), and the (perhaps-incorrect) edit to `static-gc-printer.so` described in an earlier post: <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076128.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076128.html</a> :<br>
> cd /path/to/vmkit/tools/trainer<br>
> javac HelloWorld.java<br>
> ../../Debug+Asserts/bin/vmjc -main=HelloWorld -print-aot-stats HelloWorld.class<br>
> /path/to/llvm33/bin/llc -load=../../Debug+Asserts/lib/static-gc-printer.so HelloWorld.class.bc<br>
><br>
> That produces for me a reasonable native assembly file.<br>
><br>
> Next I assemble and link, using a set of libraries/objects inspired by `llcj` and refined by a semi-automated trial-and-error:<br>
> /path/to/llvm33/bin/clang++ -g3 -O0 -o HelloWorld.class.exe HelloWorld.class.sed.s -L/path/to/vmkit_test-codechanges/Debug+Asserts/lib -L/path/to/llvm33/lib -pthread -lm -ldl -lz -lJ3 -lClasspath -lJ3Compiler -lCommonThread -lVmkit -lVmkitCompiler -lPrecompiled -lFinalMMTk -lLLVMX86Info -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Utils -lLLVMX86AsmPrinter -lLLVMExecutionEngine -lLLVMScalarOpts -lLLVMipo -lLLVMipa -lLLVMAnalysis -lLLVMInstCombine -lLLVMInstrumentation -lLLVMTarget -lLLVMJIT -lLLVMRuntimeDyld -lLLVMObject -lLLVMObjCARCOpts -lLLVMVectorize -lLLVMTransformUtils -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMMC -lLLVMCore -lLLVMSupport -rdynamic<br>
><br>
> This links and executes, but here are my problems/hacks:<br>
> * `llc` generates an assembly file with symbols (e.g., ____Vstatic_buf() and friends) that conflict with one of the archives listed above (libPrecompiled.a, which I believe is necessary for java_lang_Object and others). I basically remove those symbols (sed '/_buf$/ s/globl/weak/' HelloWorld.class.s > HelloWorld.class.sed.s) before assembling. I don't know if this is a reasonable hack or if it's causing problems.<br>
> * I get the following error at runtime (because some fields are NULL) and I can't make progress:<br>
> HelloWorld.class.exe: JavaRuntimeJIT.cpp:381: void *j3ResolveVirtualStub(j3::JavaObject *): Assertion `FI->Metadata != __null && "Wrong stack trace"' failed.<br>
><br>
> Am I on the right path, or should I be considering other methods? Or wrong entirely?<br>
><br>
> Ultimately, I propose changing `llcj` into something like a Python script that executes the appropriate utilities to start from Java source and resulting in a linked target-architecture executable, using `clang++` as compiler-driver for assembling and linking. It would be essentially a work-alike to `gcj`.<br>
><br>
> Can you help point me in the right direction?<br>
><br>
> Thank you,<br>
> Brian<br>
><br>
><br>
><br>
><br>
><br>
> Date: Mon, 1 Sep 2014 21:34:58 +0200<br>
> From: Gaël Thomas <<a href="mailto:gael.thomas00@gmail.com">gael.thomas00@gmail.com</a>><br>
> To: LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>>, Nicolas<br>
> Geoffray <<a href="mailto:nicolas.geoffray@gmail.com">nicolas.geoffray@gmail.com</a>><br>
> Subject: [LLVMdev] VMKit is retired (but you can help if you want!)<br>
> Message-ID:<br>
> <CAOWuPDcZBpt_JJ5yo5YN=C+RWbtbneXB1UGd90d0mXdnrs8=<a href="mailto:RQ@mail.gmail.com">RQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> Hi all,<br>
><br>
> So, as explained in the LLVM weekly, the VMKit project is retired. It<br>
> was a very fun project, but we don't have any manpower to maintain the<br>
> code since one year. If someone is interested by restarting the<br>
> project, just send me an email, I can help to understand the<br>
> architecture of the project and how it works. I'm pretty sure that we<br>
> can also extract a Java to LLVM compiler easily (I know that some<br>
> people are interested by that).<br>
><br>
> And I want to thank all the LLVM team for their support during these<br>
> last ten (yes ten:)) years! Without their help, it would have been<br>
> impossible to develop VMKit.<br>
><br>
> See you and thank you!<br>
> Gaël<br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
--<br>
-------------------------------------------------------------------<br>
Gaël Thomas, Associate Professor, UPMC<br>
<a href="http://pagesperso-systeme.lip6.fr/Gael.Thomas/" target="_blank">http://pagesperso-systeme.lip6.fr/Gael.Thomas/</a><br>
-------------------------------------------------------------------<br>
</blockquote></div>