[LLVMdev] TLS with MCJIT (an experimental patch)

[David Chisnall]

On 22 May 2013, at 13:23, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

> Why the private message? If unintentional, please forward this to the list.

Ooops, forgot to hit reply-all.  Didn't the LLVM lists used to default to reply-to-list behaviour?

> So, the JIT is analogous to dlopen, so it should be using general
> dynamic and local dynamic models. It is only the initial exec and
> local exec that require the dynamic linker to allocate memory at
> startup.

The dynamic linker will have allocated the memory because the TLS variable in question is provided by libc.  It is already allocated before the JIT'd code runs.  The JIT'd code just needs to refer to it.  

> If MCJIT is producing TLS code using initial exec or local exec that is a bug.
> 
> On 22 May 2013 08:14, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
>> On 22 May 2013, at 13:01, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> 
>>> On 22 May 2013 06:22, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
>>>> On 15 May 2013, at 01:17, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:
>>>> 
>>>>> I believe that assertion indicates that something didn't get loaded into the lower 2GB of address space.  That is, the memory manager isn't allocating memory in that range.
>>>>> 
>>>>> I'm sure there must be a way to allocate memory in that range on FreeBSD.  The system loader has to do it, right?  I just don't know what makes it happen.
>>>> 
>>>> I've asked around, and we don't seem to have anything that can do it.  Checking the code for rtld, it explicitly asks for memory at a specific address and keeps track of the regions it has used.
>>> 
>>> 
>>> I was under the impression that, in the small memory model, each .so
>>> had to be small, but because of the use of GOTs and PLTs they could be
>>> anywhere in memory. If we allocate the tls memory in the same
>>> allocator call that allocates space for the text section this would
>>> work, no?
>> 
>> I'm not sure what you mean by 'we' in this context.  The memory for TLS (in this instance) is allocated when libc is loaded, as one of the first things after rtld starts.  The memory will be accessed via a segment register, so the offset is actually the thing that must be resolved.  Because this is static at run time (irrespective of the TLS model, the offset doesn't change during a single program run), the MC loader could hard-code the offset, irrespective of where it ends up.  The memory for the text section in JIT'd code is allocated by the memory manager.  We do not have a way of asking rtld to allocate memory for us.
>> 
>> If we're going to go via GOTs and PLTs for calls out of JIT'd code then it seems that we're losing a lot of the benefit of the JIT, as it knows when doing code generation exactly where every function and every variable is.
>> 
>> David
>>