[LLVMdev] JIT allocates global data in function body memory
dalej at apple.com
Tue Jun 30 11:42:48 PDT 2009
On Jun 30, 2009, at 11:18 AMPDT, Jeffrey Yasskin wrote:
> On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com>
>> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote:
>>> So I (think I) found a bug in the JIT:
>>> Basically, globals used by a function are allocated in the same
>>> 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
>>> is still in the GlobalValue map, so any other code using that global
>>> will access freed memory, which will cause problems as soon as you
>>> reallocate that memory for something else.
>>> I tracked down the commit that introduced the bug:
>>> It very nicely explains what it does, but not why it does it, which
>>> I'd like to know before I change it. I couldn't find the author
>>> (johannes) on IRC so ssen told me to ask LLVMdev about this
>> 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 it so other models work as well, go ahead.
> So, you're moving code across machines without running any relocations
> on it? How can that work? Are you just assuming that everything winds
> up at the same addresses? Or is everything PC-relative on your
> platform, so all that matters is that globals and the code are in the
> same relative positions?
I am not the people actually doing this, I am the guy who changed llvm
JIT handling so that this model would work. I believe everything is
PC-relative, but I don't know details (and probably couldn't talk
about them on a public list if I did). I don't think those guys do
any freeing, so they don't have your problem.
The current model where code and data share a buffer needs to continue
to work, and I have a fairly strong preference (and so will our
client) that whatever you do should not require any changes to the
existing client code. Beyond that, I am not the kind of person who
thinks there's only one way to do things; I won't object to what you
do as long as it doesn't break what we're using now.
> How are you getting the size of the code you need to copy?
> MachineCodeInfo didn't exist when you wrote this patch, so I assume
> you've written your own JITMemoryManager. Even then, if you JIT more
> than one function, and they share any globals, you have to deal with
> multiple calls into the MemoryManager and functions that use globals
> allocated inside other buffers. You should be able to deal with having
> separate calls to allocate global space and allocate code space. You'd
> just remember the answers you gave and preserve them when copying to a
> new system.
> I'd like freeMachineCodeForFunction to avoid corrupting emitted
> globals, and with the current arrangement of information within the
> JIT, that means globals and code have to live in different
> allocations. I think Reid's suggesting a flag of some sort, with one
> setting for "freeMachineCodeForFunction works" and another for
> "globals and code are allocated by a single call into the
> MemoryManager." I'd like to avoid new knobs if it's possible, so do
> you really need that second option? Or do you just need globals to be
> allocated by some call into the MemoryManager?
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev