On 2013-01-09 11:00, deadalnix wrote:

> Isn't it horrible performancewise ?

I think it sounds like that but I don't know. I'm just trying to figure out how TLS is implemented on Mac OS X 10.7+.

-- 
/Jacob Carlborg

On 2013-01-09 11:26, Jacob Carlborg wrote:

> I think it sounds like that but I don't know. I'm just trying to figure
> out how TLS is implemented on Mac OS X 10.7+.

Also, there's nothing else that calls this tlv_get_addr function or the thunk so I'm guessing it's the compiler that calls it.

-- 
/Jacob Carlborg

On 1/9/2013 2:28 AM, Jacob Carlborg wrote:
> On 2013-01-09 11:26, Jacob Carlborg wrote:
>
>> I think it sounds like that but I don't know. I'm just trying to figure
>> out how TLS is implemented on Mac OS X 10.7+.
>
> Also, there's nothing else that calls this tlv_get_addr function or the thunk so
> I'm guessing it's the compiler that calls it.

Watcha do is something like this:

__thread int x;
int foo() { return x; }

Compile, disassemble, and look at the code generated and the fixup records. Then there's no need to guess :-)

On Wed, Jan 9, 2013 at 9:52 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> There is something to be said about proportional response. Shall we stop this now?

I propose to start another thread, maybe more constructive, where I propose a small text describing what's new in 2.061. Is that OK?

On 2013-01-09 11:38, Walter Bright wrote:

> Watcha do is something like this:
>
> __thread int x;
> int foo() { return x; }
>
> Compile, disassemble, and look at the code generated and the fixup
> records. Then there's no need to guess :-)

Sure, I've already done that. I compared one version using "__thread" and one version without "__thread". I do see the differences of the disassembly but that doesn't help me, I don't know assembly. The only interesting I could find is that it does perform a "call", the version with "__thread".

I don't have access to a machine running Lion+ but you could take a look at this:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268

That's a bugzilla issue for the same thing for GCC. The comments contain some disassembly of uses of "__thread".

-- 
/Jacob Carlborg

On Wednesday, 9 January 2013 at 10:38:33 UTC, Walter Bright wrote:
> Watcha do is something like this:
>
> __thread int x;
> int foo() { return x; }
>
> Compile, disassemble, and look at the code generated and the fixup records. Then there's no need to guess :-)

I also think this is the best way of approaching such problems. If you can, also try to find the source code for the involved code. In case of trying to understand the OS X TLS mechanism, I found the following files from dyld to be helpful:

http://opensource.apple.com/source/dyld/dyld-210.2.3/src/threadLocalHelpers.s
http://opensource.apple.com/source/dyld/dyld-210.2.3/src/threadLocalVariables.c

David

On Wed, 09 Jan 2013 01:09:21 -0800
Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, January 09, 2013 00:52:32 Andrei Alexandrescu wrote:
> > On 1/9/13 12:43 AM, Jonathan M Davis wrote:
> > > On Friday, January 04, 2013 14:13:22 Walter Bright wrote:
> > >> It's THE SAME LIST as in the bugzilla list. It's even in the same order. It's just that the bugzilla generated list is complete.
> > >> 
> > >> I don't understand your rationale that it's _far_ more user
> > >> friendly. It's
> > >> the exact same list, in the exact same order, with the exact
> > >> same text.
> > > 
> > > Okay, _far_ more friendly is probably an exaggeration
> > 
> > There is something to be said about proportional response. Shall we stop this now?
> 
> I think that it's important, and other people in this thread have agreed with me (anyone other than Walter who has disagreed has been silent on the issue). But I gather that you don't agree.
> 
> - Jonathan M Davis

Yea, this change is definitely a notable step backwards in presentation and usability.

On 2013-01-09 17:16, David Nadlinger wrote:

> I also think this is the best way of approaching such problems. If you
> can, also try to find the source code for the involved code. In case of
> trying to understand the OS X TLS mechanism, I found the following files
> from dyld to be helpful:
>
> http://opensource.apple.com/source/dyld/dyld-210.2.3/src/threadLocalHelpers.s
>
> http://opensource.apple.com/source/dyld/dyld-210.2.3/src/threadLocalVariables.c

I've already found that code. That's where I got my information from in my previous post.

-- 
/Jacob Carlborg

On Wednesday, 9 January 2013 at 10:38:33 UTC, Walter Bright wrote:
> On 1/9/2013 2:28 AM, Jacob Carlborg wrote:
>> On 2013-01-09 11:26, Jacob Carlborg wrote:
>>
>>> I think it sounds like that but I don't know. I'm just trying to figure
>>> out how TLS is implemented on Mac OS X 10.7+.
>>
>> Also, there's nothing else that calls this tlv_get_addr function or the thunk so
>> I'm guessing it's the compiler that calls it.
>
> Watcha do is something like this:
>
> __thread int x;
> int foo() { return x; }
>
> Compile, disassemble, and look at the code generated and the fixup records. Then there's no need to guess :-)

Surely __thread is redundant there, seeing as x will be TLS by default?

I tried disassembling this on os x 10.7.5

otool (the default tool for this on os x) just gave me this:

    tls_test.o:
    indirect symbol table offset is past end of file
    (__TEXT,__text) section

It couldn't see any instructions at all.

gdb disas gives this:

    0x0000000000000024 <D8tls_test3fooFZi+0>:	push   rbp
    0x0000000000000025 <D8tls_test3fooFZi+1>:	mov    rbp,rsp
    0x0000000000000028 <D8tls_test3fooFZi+4>:	mov    rdi,QWORD PTR [rip+0x0]        # 0x30 <D8tls_test3fooFZi+12>
    0x0000000000000030 <D8tls_test3fooFZi+12>:	call   0x35 <D8tls_test3fooFZi+17>
    0x0000000000000035 <D8tls_test3fooFZi+17>:	mov    eax,DWORD PTR [rax]
    0x0000000000000037 <D8tls_test3fooFZi+19>:	pop    rbp
    0x0000000000000038 <D8tls_test3fooFZi+20>:	ret

On 2013-01-09 19:53, John Colvin wrote:

> Surely __thread is redundant there, seeing as x will be TLS by default?

We're talking C here and it's not default in C.

-- 
/Jacob Carlborg