similar to: [LLVMdev] Using a function from another module

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

On 3 February 2010 14:13, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > I have not used the C api or the interpreter, but via JIT one can use > ExecutionEngine::addGlobalMapping(...) after the function decl in the > foreign module. See if there is an equivalent in the C API, which will > probably work for the interpreter given that this method is declared in >

Michael Muller 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

On Sun, Jan 10, 2010 at 8:58 AM, Michael Muller <mmuller at enduden.com> wrote: > > Michael Muller 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

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

=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?= wrote: > > I can reproduce this consistently, but only under an extremely large pile of > > code :-) I haven't tried to strip it down to minimal a test case yet, but I > > will. One salient difference with the code you've provided is that in my > > code, @a is a struct type. However, changing the example to use a

Hi Michael, did anything ever happen with this? Ciao, Duncan. On 17/01/12 14:45, Michael Muller wrote: > > So it looks like the verifier doesn't catch this condition - I think it > should. The attached program reproduces the problem - verification succeeds, > but the linker fails with a type assertion. > > BTW, if no one has the bandwidth to work on this I'm willing to

Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, without the need for a module A dec to module B impl. mapping? Garrison On Jan 10, 2010, at 10:31, Kenneth Uildriks wrote: > On Sun, Jan 10, 2010 at 8:58 AM, Michael Muller <mmuller at enduden.com> wrote: >> >> Michael Muller wrote: >>> >>> Hi all,

So it looks like the verifier doesn't catch this condition - I think it should. The attached program reproduces the problem - verification succeeds, but the linker fails with a type assertion. BTW, if no one has the bandwidth to work on this I'm willing to attempt a fix, assuming that you agree that the verifier should discover this condition. Michael Muller wrote: > >

Hi all, Can someone point me to a good way to get debug info from jitted code at runtime? Ideally I'm looking for something that given the current IP address, provides function name, filename and line number. The context of this request is that I'm trying to inject a stack-trace into an exception object. =============================================================================

Hi all, I've been waiting for almost three months now to get a patch committed to LLVM that fixes what I consider to be a fairly significant bug in the JIT (http://llvm.org/bugs/show_bug.cgi?id=13678) but I've been having a hard time getting traction on it. So far Duncan Sands is the only one who has given it any attention, but as of the last time I checked it still wasn't committed

Unfortunately, LLVM doesn't really know how to generate debug info for JITed code yet. All it can tell you or a debugger is the symbol and the unwind information for unwinding exceptions through JITed code. Hopefully the MC JIT will make that problem go away. Reid On Wed, Mar 30, 2011 at 10:05 AM, Michael Muller <mmuller at enduden.com> wrote: > > Hi all, > > Can someone

On Mon, Jan 11, 2010 at 1:39 PM, Jeffrey Yasskin <jyasskin at google.com> 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

=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?= wrote: > On 11/01/12 07:50 AM, Michael Muller wrote: > > > > Hi all, I was looking at the ValueMapper code this morning and I notice that > > it doesn't do type mapping for GlobalValues. Is this correct? > > > > I ask because I am seeing a case where I'm failing type assertions from > >

Hi Michael, don't forget that Eric made some comments that you never replied to. Since his comments seemed pretty pertinent I wasn't prepared to apply your patch without a satisfactory response from you. Ciao, Duncan. > I've been waiting for almost three months now to get a patch committed to LLVM > that fixes what I consider to be a fairly significant bug in the JIT >

> I can reproduce this consistently, but only under an extremely large pile of > code :-) I haven't tried to strip it down to minimal a test case yet, but I > will. One salient difference with the code you've provided is that in my > code, @a is a struct type. However, changing the example to use a minimal > structure doesn't trigger the assertion failure. Is the

Eric Christopher wrote: > > On Aug 21, 2012, at 2:12 PM, Michael Muller <mmuller at enduden.com> wrote: > > > > > Hi, I found a bug in the code that generates exception tables, I've attached > > what I think is the correct fix. > > > > When you run out of space writing to a buffer, the buffer management code > > simply stops writing at the

Hi, I found a bug in the code that generates exception tables, I've attached what I think is the correct fix. When you run out of space writing to a buffer, the buffer management code simply stops writing at the end of the buffer. It is the responsibility of the caller to verify that it has stayed in bounds and perform a retry with a larger memory estimate if not. The function writing code

On Aug 21, 2012, at 2:12 PM, Michael Muller <mmuller at enduden.com> wrote: > > Hi, I found a bug in the code that generates exception tables, I've attached > what I think is the correct fix. > > When you run out of space writing to a buffer, the buffer management code > simply stops writing at the end of the buffer. It is the responsibility of > the caller to

On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > without the need for a module A dec to module B impl. mapping? > > Garrison Nope. You cannot place a call instruction into one module whose callee is a Function from another module. You