similar to: [LLVMdev] introspecting debug info from the JIT

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

Also note that there is a third optional std::string* argument which if non-NULL gets set to an appropriate error message. Reid 2009/12/12 Török Edwin <edwintorok at gmail.com>: > On 2009-12-12 18:19, Michael Muller wrote: >> Hi all, I'm trying to upgrade from LLVM 2.5 -> 2.6, and when I create my >> execution engine (ExecutionEngine::create(module)) I get back 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

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)

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

=?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, 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

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

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

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

Kenneth Uildriks wrote: > 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

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 ModuleLinker::linkGlobalInits() when an array initializer references an external global. It looks like the external global is being mapped directly and this causes an element

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 >

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

Hi Clemens - thanks for your response. Clemens Hammacher wrote: > Hi Michael, > > since noone of the experts answered, let me share our experiences. We > recently had exactly the same problem, I posted on this list on January > 31st. > I didn't follow Duncans advice to "just use the linker", since for > several reasons we wanted to have unique struct types

=?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 all, We've run into a tricky situation in our work on the Crack compiler and I'm hoping that someone on this list can help us find the best solution. We're currently trying to implement "module caching" for Crack, similar to the feature in Python where module bitcode is persisted at compile time. When we import a module, before compiling the module we check for a

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