VMKit build problems; can't use LLVM3.4.2 ?

Greetings,

I've been using LLVM and Clang for some time, but I'm new to the list and new to VMKit; please advise if I should post this elsewhere.

VMKit doesn't seem to build with LLVM/Clang 3.4.2 -- seems that one must use LLVM3.3. I see the following error:

VmkitGCPrinter.cpp:363:53: error: too many arguments to function call, expected 2, have 3
      AP.OutStreamer.EmitValue(address, IntPtrSize, 0);

I now see the vmkit build instructions (http://vmkit.llvm.org/get_started.html) explicitly say to use LLVM and Clang 3.3; using that version fixes the above. It seems to be that the signature of (at least) one function from the LLVM library (e.g., llvm/MC/MCStreamer.h::EmitValue(...)) changed from LLVM 3.3 => 3.4.2 .

Is there any plan to migrate vmkit to build to build against LLVM >= 3.4.2 ? This is probably disruptive (ABI breakage?) but seems prudent; perhaps there are other fundamental problems in this migration. I'd be willing to contribute to a 3.4.2-compatible branch if there is one (I don't see an obvious candidate in svn repo http://llvm.org/svn/llvm-project/vmkit/branches).

Have I got this correct, or I missing something else?

Incidentally, this seems to be the same behavior/problem as reported on 20 January 2014 by neoedmund (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069558.html), which is solved by building using LLVM3.3 (no response seen).

Thank you!
Brian

Hi Brian,

It's common for some projects to attach themselves to a specific
version of LLVM when the team doesn't have time to merge their code to
trunk every other week, which can be very costly in the long term.
However, any project that aims to be relevant in the LLVM community
has to follow trunk, not a specific release, not even the current
release. On projects whose aim is to present a proof-of-concept or to
focus on a completely unrelated issue (VMKit, LLVMpipe), this seems to
be the choice to stick to a release or even an SVN revision number.
But for any compilation tool, it should never be.

LLVM APIs do change considerably, even between a few commits apart.
So, even if you support 3.5svn trunk, you can become obsolete in a
matter of weeks. This dependency cannot be solved by LLVM supporting
old APIs, or the code would have more legacy than features, and has to
become a motto of the side projects themselves. Thus, unless VMKit
developers are willing to follow trunk and have buildbots following
the rest, it won't happen.

Of course, as with any open source project, *you* could be the person
to drive this, in case other VMKit developers are unwilling to take
the extra work. :slight_smile:

cheers,
--renato

Hi Brian,

The development of VMKit is a little bit stuck because we don't have
any contributor. Basically, I'm alone on the project and I don't have
any time for development (the engineers and PhD students that were
involved in the project are all gone).

As you can see, we only support LLVM 3.3. If you are interested in
helping porting VMKit for a newer version, I can help to explain how
VMKit is designed and to explain how the tricky parts of the code
work? Otherwise, I have started an implementation of VMKit for MCJIT
and a newer version of LLVM one year ago (branch mcjit), but I'm
unable to find any time to continue since january. But it means that I
know what we have to do to follow the last changes made in LLVM :slight_smile:

So, if you are interested in contributing, just tell me.

See you,
Gaël

Hi Gaël, Renato --

Thanks very much to both of you for the response. I appreciate the fact that VMKit exists, and understand pegging against a release, and the current development situation.

As I said in my original email, I'm certainly willing to contribute to this or something related. That said, I'm interested in a (very) narrow subset of VMKit... so I want to first be sure that I'm barking up the correct tree! If this gets into a deeper discussion, we could take it off-list.

My current goal is to explore AOT compilation of Java for the LLVM system. Is anyone doing this or interested in same? Is VMKit's vmjc the right option?

I saw a few options:
* DragonEgg
=> using GCC parsers as front-end (i.e., gcj)
=> but http://dragonegg.llvm.org says Java support is poor.
* LLVM java-frontend
=> https://llvm.org/svn/llvm-project/java/trunk/docs/java-frontend.txt but not listed on the LLVM projects page
=> this project looks stale or abandoned; last commit in 2007? (am I wrong?).
* Zero and Shark
=> http://icedtea.classpath.org/wiki/ZeroSharkFaq
=> Intended for JIT, not much information available, looks stale (2011).
* VMKit's vmjc
=> looks like it is current and functional
=> .class => .ll translation is a reasonable path.

So, my questions are rather broad at this point:
* How many use or depend on VMKit / vmjc? If it's in broad use, perhaps this is a good path.
* Is there something better for the narrow application of AOT for Java?

If the answers to the above are reasonable, let's talk more about specifics...

Brian