[LLVMdev] JIT allocates global data in function body memory
aph at redhat.com
Tue Jun 30 12:18:06 PDT 2009
Dale Johannesen wrote:
> 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 presume (hope, really) that we don't end up with code and data in the
same page. From
Intel® 64 and IA-32 Architectures Optimization Reference Manual:
Assembly/Compiler Coding Rule 57. (H impact, L generality) Always put
code and data on separate pages.
Sorry, I guess you know this already.
More information about the llvm-dev