search for: tlsgd

...to the asmprinters. One thing that is driving me nuts is that the asmprinters currently "reverse engineer" a lot of information when printing an operand that isel had when it created it. I'm specifically talking about all the suffixes generated by isel, like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc. These are all "magic" things that the assembler uses (for example, it generates a reference to a global's GOT entry instead of to the global itself). The thing that is really frustrating to me is that the asmprinters need to reverse engineer what isel *me...

...n 'unsigned char' slot to > MachineOperand that holds a target-specific enum value. The code in > asmprinter would be reduced to: > > switch (theoperandenum) { > case X86::MO_Flag_non_lazy_ptr: > O << "$non_lazy_ptr"; > break; > case X86::MO_Flag_TLSGD: > O << "@TLSGD"; > break; > case X86::MO_Flag_NTPOFF: > O << "@NTPOFF"; > break; > > > etc. The possible set of suffixes and modifiers are all target- > specific, so the main code generator would just pass them through (as > it...

...namic 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. OK. Are we generating generic dynamic code to do so? It will look like .byte 0x66 leaq x at tlsgd(%rip),%rdi ; R_X86_64_TLSGD to symbol x (MCJIT has to create a GOT entry) .word 0x6666 rex64 call __tls get_addr at plt ; R_X86_64_PLT32 to __tls_get_addr (MCJIT has to create a GOT and a PLT entry) This should work from any place in memory. I wouldn't be surprised if these relocations...

On 1 Oct 2013, at 14:49, Tim Northover <tnorthover at apple.com> wrote: > We're hoping to get rid of the old one soon, but there are one or two features that don't quite work there yet. Lazy compilation is the only one I know of, since we got multi-module support yesterday. But there may be more. Can MCJIT handle thread-local references? This was the feature keeping us on the

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

Hi David, 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. -Andy -----Original Message----- From: Dr