similar to: [LLVMdev] mapping types from a bitcode module

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 even in the separate modules. > 1) duplicate the LinkModule internal code and copy the module we

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

On 2/27/12 8:27 PM, Michael Muller wrote: >>> 3) destructively convert all of the types in the imported module to our >>> existing types. >> >> That's what we actually implemented, following the idea I described in >> the mentioned post. We don't identify identical struct types by their >> name, since even in the new type system, names don't

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

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

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

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

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 >

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

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

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

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

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

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

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

Pinging again, more loudly :-) Michael Muller wrote: > > Ping. (looking for someone to review or commit this, thanks) > > Michael Muller wrote: > > > > Thanks, Duncan - > > > > > Hi Michael, > > > > > > > --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 163478) > > > > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp