The clang compiler in clang 3.0 and Xcode 4.2 currently provides tis support on darwin11. This same ability to generate the required tis assembly for darwin11 should be added to FSF gcc.
If you could snapshot some codegen, say void foo() { static __thread int i = 42; ++i; } or somesuch, we could see if they wired it up the same was as gcc is normally wired. I suspect it should be fairly close. I'm thinking this should be easy to wire up.
somewhat different from the output generated, for example for x86-64-unk-linux (-fPIC). .... this is what clang version 3.1 (trunk 150612) : gives. $ cat ../tests/thr-0.c int foo (int f) { static __thread int ff ; ff += f; return ff; } $ ./install/bin/clang ../tests/thr-0.c -target x86_64-apple-darwin11 -S $ more thr-0.s .section __TEXT,__text,regular,pure_instructions .globl _foo .align 4, 0x90 _foo: ## @foo .cfi_startproc ## BB#0: ## %entry pushq %rbp Ltmp2: .cfi_def_cfa_offset 16 Ltmp3: .cfi_offset %rbp, -16 movq %rsp, %rbp Ltmp4: .cfi_def_cfa_register %rbp subq $16, %rsp movl %edi, -4(%rbp) movl %edi, -8(%rbp) ## 4-byte Spill movq _foo.ff@TLVP(%rip), %rdi callq *(%rdi) movl (%rax), %ecx movl -8(%rbp), %edx ## 4-byte Reload addl %edx, %ecx movl %ecx, (%rax) movl %ecx, %eax addq $16, %rsp popq %rbp ret .cfi_endproc .tbss _foo.ff$tlv$init, 4, 2 ## @foo.ff .section __DATA,__thread_vars,thread_local_variables _foo.ff: .quad __tlv_bootstrap .quad 0 .quad _foo.ff$tlv$init .subsections_via_symbols ===== $ ./install/bin/clang ../tests/thr-0.c -target i686-apple-darwin11 -S $ more thr-0.s .section __TEXT,__text,regular,pure_instructions .globl _foo .align 4, 0x90 _foo: ## @foo ## BB#0: ## %entry pushl %ebp movl %esp, %ebp subl $8, %esp calll L0$pb L0$pb: popl %eax movl 8(%ebp), %ecx movl %ecx, -4(%ebp) movl _foo.ff@TLVP-L0$pb(%eax), %eax movl %ecx, -8(%ebp) ## 4-byte Spill calll *(%eax) movl (%eax), %ecx movl -8(%ebp), %edx ## 4-byte Reload addl %edx, %ecx movl %ecx, (%eax) movl %ecx, %eax addl $8, %esp popl %ebp ret .tbss _foo.ff$tlv$init, 4, 2 ## @foo.ff .section __DATA,__thread_vars,thread_local_variables _foo.ff: .long __tlv_bootstrap .long 0 .long _foo.ff$tlv$init .subsections_via_symbols === $ cat ../tests/thr-1.c int foo (int f) { static __thread int ff = 1234; ff += f; return ff; } ... much the same except popq %rbp ret .cfi_endproc .section __DATA,__thread_data,thread_local_regular .align 2 ## @foo.ff _foo.ff$tlv$init: .long 1234 ## 0x4d2 .section __DATA,__thread_vars,thread_local_variables _foo.ff: .quad __tlv_bootstrap .quad 0 .quad _foo.ff$tlv$init --- and popl %ebp ret .section __DATA,__thread_data,thread_local_regular .align 2 ## @foo.ff _foo.ff$tlv$init: .long 1234 ## 0x4d2 .section __DATA,__thread_vars,thread_local_variables _foo.ff: .long __tlv_bootstrap .long 0 .long _foo.ff$tlv$init
Also in clang 3.0, I see test/CodeGen/darwin-thread-specifier.c which contains... // RUN: %clang_cc1 -triple x86_64-apple-macosx10.7.0 -emit-llvm -o - %s | FileCheck %s // CHECK: @b = thread_local global i32 5, align 4 __thread int b = 5; whereas their test/CodeGen/thread-specifier.c has... // RUN: %clang_cc1 -triple i686-pc-linux-gnu -emit-llvm -o - %s | FileCheck %s // CHECK: @b = external thread_local global // CHECK: @d.e = internal thread_local global // CHECK: @d.f = internal thread_local global // CHECK: @a = thread_local global __thread int a; extern __thread int b; int c() { return *&b; } int d() { __thread static int e; __thread static union {float a; int b;} f = {.b = 1}; return 0; }
Created attachment 26795 [details] test/MC/MachO/tls.s from llvm svn
The test/MC/MachO/tls.s from llvm svn also may have some useful hints on the expected assembly for tis on darwin11 and later.
Chris Lattner kindly pointed out that the initial tis support for darwin was added in r105381. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100531/102158.html... [llvm-commits] [llvm] r105381 - in /llvm/trunk/lib/Target/X86: AsmPrinter/X86AsmPrinter.cpp AsmPrinter/X86MCInstLower.cpp X86ISelDAGToDAG.cpp X86ISelLowering.cpp X86ISelLowering.h X86Instr64bit.td X86InstrInfo.h X86InstrInfo.td URL: http://llvm.org/viewvc/llvm-project?rev=105381&view=rev Log: Add first pass at darwin tls compiler support.
I'm kind of confused about whether gcc actually has tls support on darwin or not; I could have sworn I was able to use gcc 4.8 to compile some code that used `__thread` on darwin the other day, but according to this bug, that should have been impossible, right? Did gcc just ignore it silently or something?
Seems to work to me in gcc-4.6: ~ $ cat test_thread.c #include <pthread.h> #include <stdio.h> #define NUM_THREADS 5 int __thread value; void * test_thread(void *arg) { return &value; } int main(void) { int i; pthread_t thread[NUM_THREADS]; for(i=0; i < 5; i++) { pthread_create(&thread[i], NULL, test_thread, NULL); } for(i=0; i < 5; i++) { void *loc; pthread_join(thread[i], &loc); printf("%p\n", loc); } return 0; } $ gcc-mp-4.6 test_thread.c $ ./a.out 0x7fc7b3d00118 0x7fc7b3e00118 0x7fc7b3f00118 0x7fc7b3d00118 0x7fc7b3c03b28 $ gcc-mp-4.6 --version gcc-mp-4.6 (MacPorts gcc46 4.6.4_5+universal) 4.6.4 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(In reply to Jeremy Huddleston Sequoia from comment #8) > Seems to work to me in gcc-4.6: TLS _is_ supported on Darwin by means of emutls (emulation using pthreads interfaces). This enhancement request is for native TLS support, which would be more efficient.
Ah, gotcha. In that case, please retitle as well to indicate such. Prior to gcc-4.5, even support via emutls was not available on darwin, so some people in #macports thought that's what this ticket was referring to. Thanks.
Fixed title to reflect that this is for native tls.
(In reply to Jeremy Huddleston Sequoia from comment #10) > Ah, gotcha. In that case, please retitle as well to indicate such. Prior to > gcc-4.5, even support via emutls was not available on darwin, so some people > in #macports thought that's what this ticket was referring to. Thanks. (that was me in https://trac.macports.org/ticket/44062#comment:59 for reference... anyways, thanks for clearing this up!)
This could potentially arrive with the arm64 darwin port: https://github.com/iains/gcc-darwin-arm64/issues/1