Another question to add to the pile

(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 :slight_smile:

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. :slight_smile:

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 :slight_smile:

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 :slight_smile:

Sounds fun :slight_smile:

-Chris

Chris Lattner wrote:

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.

Cool, that's what I needed. I was a little confused by the description of that option in --help, which says "Load the specified plugin". I usually associate the word "plugin" with something that has a specific interface, not just an arbitrary .so.

-- Talin