[LLVMdev] bug in the JIT global variable emitter

[Evan Cheng]

On Oct 14, 2008, at 2:32 PM, Nuno Lopes wrote:

> [resending since the previous copy was apparently dropped by the  
> mailing
> list]
>
>>> Today I found a nice bug in the JIT global variable emitter.
>>> The problem may lead to an assert() failure when doing the  
>>> following:
>>> 1) compile some function
>>> 2) emit a global variable
>>> 3) compile another function. an assert() may trigger in the JIT  
>>> memory
>>> manager
>>>
>>> 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
>> user
>> 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  
>> code
>> 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  
> buffer.
> 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  
> (i.e.
> when dumping a global variable out of the scope of a function  
> compilation).
> The patch is at:
> http://web.ist.utl.pt/nuno.lopes/llvm_jit_global_emitter2.txt

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  
> JITed,
> which raises a question: shouldn't it generate the GV to some non- 
> executable
> 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  
alternative.

Evan

>
>
> Thanks,
> Nuno
>
> 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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev