search for: allocateseparategvmemori

> That's me (and I'm not on IRC because I like messages to be > archived).  The reason everything needs to go in the same buffer is > that we're JITting code on one machine, then sending it to another to > be executed, and references from one buffer to another won't work in > that environment.  So that model needs to continue to work.  If you > want to generalize

On Mon, Jun 29, 2009 at 9:23 PM, Reid Kleckner<rnk at mit.edu> wrote: >> That's me (and I'm not on IRC because I like messages to be >> archived).  The reason everything needs to go in the same buffer is >> that we're JITting code on one machine, then sending it to another to >> be executed, and references from one buffer to another won't work in

On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > So I (think I) found a bug in the JIT: > http://llvm.org/bugs/show_bug.cgi?id=4483 > > Basically, globals used by a function are allocated in the same buffer > as the first code that uses it. However, when you free the machine > code, you also free the memory holding the global's data. The address > is still in the

On OS X (10.6.2) running on an Intel Core 2 duo with LLVM 2.7 pulled about a month ago from CVS and built in debug mode: Using the JIT system with exception handling, I am having issues with type infos. "Finally" code (llvm.eh.selector intrinsic call with 0) works fine (correct landing pads found), as does this call with one type info. My type infos are each 64 bit array GlobalVariables

So I (think I) found a bug in the JIT: http://llvm.org/bugs/show_bug.cgi?id=4483 Basically, globals used by a function are allocated in the same buffer as the first code that uses it. However, when you free the machine code, you also free the memory holding the global's data. The address is still in the GlobalValue map, so any other code using that global will access freed memory, which