[LLVMdev] Another question to add to the pile

[Chris Lattner]

On Aug 25, 2007, at 10:04 PM, Talin wrote:
> (Apologies if my questions are misdirected; I looked at the  
> developers mailing list, and by the content I'm guessing that it's  
> primarily intended for LLVM developers, not LLVM users. If there's  
> a better place to ask general user questions, I'd be happy to  
> redirect my questions there.)

It's no problem.  llvmdev is for both :)

> So one of my design goals is to be able to link against standard C  
> libraries (both static and dynamic) using a foreign function  
> interface. I want users of my language to be able to write a  
> wrapper for, say, zlib without having to write a bunch of C glue  
> code. C# does this pretty well for DLLs, I'd like to do something  
> similar for .libs as well.

Yep, ok.

> I see that in my various experiments with 'lli', that references to  
> standard libc functions such as 'fopen' and 'printf' are resolved  
> without any problem, and without me having to specify any  
> additional parameters on the command line.

lli does this by calling 'dlsym' on functions that it doesn't know  
about.  This allows references to printf to be resolved to the printf  
that is already in the address space.  Since the JIT uses the same  
ABI as the native system, this usually works great.  We could also  
allow overriding resolution on a per-symbol basis as well if it would  
be useful (i.e. the jit would invoke a callback).

> However, I'm stumped as to how to resolve references to external C  
> functions in my own runtime. I saw the "addLibrary" function in the  
> stacker example, but that just takes a module name - it doesn't  
> tell the linker/interpreter where the module is located, and there  
> doesn't appear to be any command-line options in lli to tell it  
> where to find external libraries.

You can use the -load command to do this:

lli -load /path/to/your.so foo.bc

this will cause it to dlopen the specified .so/.dylib.

In practice, lli is a developer tool that is just a thin veneer  
around the JIT libraries.  if you're developing something for the end- 
users of your language, you will probably want to make some other  
small app that wraps around the jit that handles the magic in your  
system transparently for them. :)

> Of course, I'm probably misunderstanding everything. In that case I  
> can only hope that the depth of my cluelessness is a useful data  
> point :)

Not at all.

> In the mean time, I guess I'll work on other stuff in my front end,  
> like getting Koenig lookup working for operator overloads, and  
> working on my garbage collector :)

Sounds fun :)

-Chris