January 09, 2013 Re: Shared Libraries [was Re: D 1.076 and 2.061 release] | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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 |
January 09, 2013 Re: Shared Libraries [was Re: D 1.076 and 2.061 release] | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 |
January 09, 2013 Re: Shared Libraries [was Re: D 1.076 and 2.061 release] | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 :-)
|
January 09, 2013 Re: D 1.076 and 2.061 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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? |
January 09, 2013 Re: Shared Libraries [was Re: D 1.076 and 2.061 release] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
January 09, 2013 Re: Shared Libraries [was Re: D 1.076 and 2.061 release] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
January 09, 2013 Re: D 1.076 and 2.061 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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.
|
January 09, 2013 Re: Shared Libraries [was Re: D 1.076 and 2.061 release] | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
January 09, 2013 Re: Shared Libraries [was Re: D 1.076 and 2.061 release] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
January 09, 2013 Re: Shared Libraries [was Re: D 1.076 and 2.061 release] | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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 |
Copyright © 1999-2021 by the D Language Foundation