[LLVMdev] bug in the JIT global variable emitter
evan.cheng at apple.com
Tue Oct 14 23:20:30 PDT 2008
On Oct 14, 2008, at 2:32 PM, Nuno Lopes wrote:
> [resending since the previous copy was apparently dropped by the
>>> Today I found a nice bug in the JIT global variable emitter.
>>> The problem may lead to an assert() failure when doing the
>>> 1) compile some function
>>> 2) emit a global variable
>>> 3) compile another function. an assert() may trigger in the JIT
>>> This happens because the JIT global variable emitter is using the
>>> MachineCodeEmitter::allocate() function, which uses memory allocated
>>> by the
>>> JIT memory manager (which should be used for functions only).
>> No, this was a deliberate change, 54442. We have a situation where a
>> wants to emit JIT code on one machine, then send it off to another
>> machine to
>> execute. Putting statically allocated data in the same buffer as
>> is the
>> easiest approach to make this work, although there may be others.
> Ok, thanks for the explanation. So my first patch doesn't work.
> Also, to be
> clear, this bug has nothing to do with overflowing the JIT memory
> I made another one that takes keeps the allocation of global
> variables in
> the JIT buffer, but it creates a new mem block if it doesn't exist
> when dumping a global variable out of the scope of a function
> The patch is at:
Sorry, I am still not able to understand the problem. Is there a bug
in the default memory manager? From your patch it seems like there is
a real bug. What is the assertion that you ran into?
> The problem only happens when calling
> ExecutionEngine::getPointerToGlobal(someGV) from some non-llvm
> program. If
> the function is called when JITing a function, it works, since it
> will dump
> the global variable to the memory reserved to the function being
> which raises a question: shouldn't it generate the GV to some non-
> memory block?? My patch doesn't attempt to fix this last concern.
There are two ways to go about this. Either we enhance memory manager
interface to create non-executable memory for GVs etc. Or we keep the
memory manager simple and let the JIT change the privilege as it sees
fit. I prefer the later unless there is a good argument for an
> P.S.: the control flow of this bug is quite complex, so feel free to
> ask if
> you don't get what the problem is.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev