[LLVMdev] Integrating LLVM in an existing project

[Reid Spencer]

Hi Nicolas,

On Thu, 2007-04-05 at 14:10 +0200, Nicolas Geoffray wrote:
> Hi everyone,
> 
> After some time hacking on llvm, let me introduce myself :)
> I'm a PhD student at the French university Pierre et Marie Curie in 
> Paris. I work on a project
> called the "Virtual Virtual Machine" project. You can find some (dated) 
> information on the
> website http://vvm.lip6.fr.
> 
> Basically it's a "low level virtual machine" :) with a just in time 
> compiler called the VPU, an execution environment
> (GC + threads) and it parses a lisp-like language that is translated to 
> the VPU's internal bytecode.

Interesting project. I wish you could talk about it at the Developer's
Meeting (http://llvm.org/DevMtgMay2007.html :)

.. snip ..

> So here are a few questions whose answers will help me go through this issue
> 1) Is the Chris' exception handling note actually implemented or is it 
> still in project? 

I have signed up to implemented this (PR1269) just as Chris' note
states. HLVM needs it for much the same reason that VVM does.  I hope to
address this in late April. I'm not sure if it will make it into the 2.0
release (if it does, it will be close).

> And how difficult do you expect it to be? (Even if I have implemented
> some stuff in llvm, I am still not entirely comfortable with the code)

Well, its not conceptually difficult. At the LLVM IR level its pretty
easy: add an unwind target to a basic block and remove the invoke
instruction. Its dealing with the consequence of those two changes. It
affects many passes and all targets. The changes required individually
are not too bad, but there are a lot of them. See the work plan in
PR1269.

> 2) The llvm.dbg.stoppoint: how far is it actually implemented?

This is fully implemented in static compilations and works well with GDB
(i.e. you can debug a program generated by LLVM quite well).  For JIT,
the reason its not implemented is because its unclear how the
information would be used. Would one want to run LLI under GDB and
actually debug the executed program? If so, where does all the debug
information go? GDB doesn't read debug information out of LLVM IR
representation :) We don't know of a way to generate it on the fly in a
form GDB can consume (it prefers DWARF in a file).

Another option is to implement a debugger directly in LLI that knows
about LLVM debug information. This is somewhat like the java approach
(running a debug version of the VM).

So, the question really is, how do you want to use this in the JIT? 

> 3) Getting the address of basic blocks: is there a workaround?

I don't know. I'll let someone else answer this.  This has been
discussed several times but I wasn't paying attention to the
answers/results ;)

> 
> Thanks a lot for your answers. And don't hesitate to ask me more infos 
> if things aren't clear in my explanations.

It was quite clear! Thanks for letting us know.

Reid.

> 
> Best,
> Nicolas
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev