similar to: [LLVMdev] ValueMapper question: no type mapping for GlobalValue?

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 > ModuleLinker::linkGlobalInits() when an array initializer references an > external global. It looks

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

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

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

> 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

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

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

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

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

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

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