[LLVMdev] Interpreter with multiple modules.
James Williams
junk at giantblob.com
Wed Feb 3 07:44:18 PST 2010
On 3 February 2010 15:29, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote:
> Hi James,
>
> > This is interesting. I've just implemented dynamic loading of bitcode
> modules into lli for my project. I did this by hacking lli using the Linker
> class. Is ExecutionEngine::addGlobalMapping() preferred for this purpose?
>
> I'm not sure about the preferred way, but at least for the JIT, here is an
> email from Jeffrey
> concerning a previous thread. The issue in that thread was solved via use
> of
> ExecutionEngine::addGlobalMapping(...). I don't know if the inability of
> the JIT or
> interpreter systems to automatically search in other modules is by design
> or not.
>
Hi Garrison,
Thanks for that. I got the same error that Michael Muller posted below and
just assumed I'd need to use the linker to resolve it. I'm linking
dynamically loaded modules on demand into the existing main module for the
running program created by lli on startup. This seems to work on small test
cases but I've no idea if this is the right thing to do (I doubt it's thread
safe for example given the naive way I'm doing it). I think I need to go
read the source and documentation!
-- James
>
> Garrison
>
> On Jan 11, 2010, at 14:39, Jeffrey Yasskin wrote:
>
> > The JIT tries to handle this in some cases
> > (
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/ExecutionEngine.cpp?annotate=92771#l942
> ),
> > but doesn't handle it for functions. There aren't any tests, so I'm
> > not surprised it's broken.
> >
> > The JIT would be simpler if we just dropped multiple-module support
> > and asked people to link their modules together before trying to JIT
> > them. Is there a reason you can't do that?
> >
> > If there is, could you write a test for
> >
> http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/
> > that exercises the behavior you want, and file a bug with it attached?
> > I'm not likely to actually implement that any time soon, but having a
> > bug with a test will make it easier for someone else to pick it up.
> >
> > Thanks,
> > Jeffrey
> >
> > On Fri, Jan 8, 2010 at 4:49 PM, Michael Muller <mmuller at enduden.com>
> wrote:
> >>
> >> Hi all,
> >>
> >> I'm trying to use a function defined in one LLVM module from another
> module
> >> (in the JIT) but for some reason it's not working out. My sequence of
> >> activity is roughly like this:
> >>
> >> 1) Create moduleA
> >> 2) Create moduleB with "func()"
> >> 3) execEng = ExecutionEngine::create(
> >> new ExistingModuleProvider(moduleB));
> >> 4) execute "func()" (this works fine)
> >> 4) add "func()" to moduleA as a declaration (no code blocks) with
> External
> >> linkage.
> >> 5) execEng->addModuleProvider(new ExistingModuleProvider(moduleA));
> >> 6) run a function in moduleA that calls "func()"
> >>
> >> I get:
> >> LLVM ERROR: Program used external function 'func' which could not be
> resolved!
> >>
> >> I'm guessing I'm either going about this wrong or missing something.
> Can
> >> anyone offer me some insight?
> >>
> >>
> =============================================================================
> >> michaelMuller = mmuller at enduden.com | http://www.mindhog.net/~mmuller<http://www.mindhog.net/%7Emmuller>
> >>
> -----------------------------------------------------------------------------
> >> We are the music-makers, and we are the dreamers of dreams
> >> - Arthur O'Shaughnessy
> >>
> =============================================================================
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100203/3f321e28/attachment.html>
More information about the llvm-dev
mailing list