On 25 March 2012 21:29, Jacob Carlborg wrote:
> On 2012-03-25 20:34, Martin Nowak wrote:
>
>> Sorry,
>> that might have been misleading.
>> The point I was trying to make is that D's TLS support shouldn't
>> deviate from the native platform TLS if one is available. I've just
>> tried it out, and i
On 2012-03-25 20:34, Martin Nowak wrote:
Sorry,
that might have been misleading.
The point I was trying to make is that D's TLS support shouldn't
deviate from the native platform TLS if one is available. I've just
tried it out, and indeed I can access C TLS variables from D.
Ok. Yes, if a nati
On Sun, 25 Mar 2012 16:29:25 +0200, Jacob Carlborg wrote:
On 2012-03-23 12:55, Martin Nowak wrote:
Just another point about TLS.
extern(C) /*__thread*/ int foo;
At some point you want to be able to access C++ TLS variables
so emulation should not replace native TLS support.
So C++ TLS is
On 2012-03-23 12:55, Martin Nowak wrote:
Just another point about TLS.
extern(C) /*__thread*/ int foo;
At some point you want to be able to access C++ TLS variables
so emulation should not replace native TLS support.
So C++ TLS is not using the same implementation as the C extension __thread
On 2012-03-23 06:03, Martin Nowak wrote:
On Mon, 19 Mar 2012 10:40:25 +0100, Jacob Carlborg wrote:
As I understand it, in the native ELF implementation, assembly is used
to access the current module id, this is for FreeBSD:
http://people.freebsd.org/~marcel/tls.html
This is how ___tls_get_addr
Am Fri, 23 Mar 2012 13:05:55 +0100
schrieb "Martin Nowak" :
> On Fri, 23 Mar 2012 11:02:44 +0100, Johannes Pfau
> wrote:
>
> > For FreeBSD, this is easy again, dtv[1] contains the size of the
> > dtv. But that's probably nonstandard.
>
> Yeah, seems to be non-standard.
> There might also be is
On Fri, 23 Mar 2012 11:02:44 +0100, Johannes Pfau
wrote:
For FreeBSD, this is easy again, dtv[1] contains the size of the dtv.
But that's probably nonstandard.
Yeah, seems to be non-standard.
There might also be issues with outdated dtv's.
Just another point about TLS.
extern(C) /*__thread*/ int foo;
At some point you want to be able to access C++ TLS variables
so emulation should not replace native TLS support.
I guess the OSX emulated tls code will also be adapted to support
multiple modules? I guess we can just wait until your changes are
merged into DMD and then think about emulated TLS again.
We're already merging since 3 month or so.
Am Fri, 23 Mar 2012 05:48:46 +0100
schrieb "Martin Nowak" :
> On Mon, 19 Mar 2012 16:57:29 +0100, Johannes Pfau
> wrote:
>
> > The only way to access all loaded library is dl_iterate_phdr. But
> > I'm not sure if it provides all necessary information.
>
> Yes it does.
>
> The drawback is that
Am Fri, 23 Mar 2012 06:06:39 +0100
schrieb "Martin Nowak" :
> On Mon, 19 Mar 2012 09:15:08 +0100, Johannes Pfau
> wrote:
>
> > And how do we get the TLS initialization data? If we placed it into
> > an array, like DMD does on OSX, we could use dlsym for dlopened
> > libraries, but what about ini
On Mon, 19 Mar 2012 09:15:08 +0100, Johannes Pfau
wrote:
And how do we get the TLS initialization data? If we placed it into an
array, like DMD does on OSX, we could use dlsym for dlopened libraries,
but what about initially loaded libraries?
That doesn't work because the symbols would coll
On Mon, 19 Mar 2012 10:40:25 +0100, Jacob Carlborg wrote:
As I understand it, in the native ELF implementation, assembly is used
to access the current module id, this is for FreeBSD:
http://people.freebsd.org/~marcel/tls.html
This is how ___tls_get_addr is implemented on FreeBSD ELF i386:
On Mon, 19 Mar 2012 16:57:29 +0100, Johannes Pfau
wrote:
The only way to access all loaded library is dl_iterate_phdr. But I'm
not sure if it provides all necessary information.
Yes it does.
The drawback is that it eagerly allocates the TLS block.
https://github.com/dawgfoto/druntime/blob/
On 21 March 2012 13:17, Johannes Pfau wrote:
> Am Mon, 19 Mar 2012 16:14:36 +
> schrieb Iain Buclaw :
>
>
>>
>> Initial things to think about on the top of my head:
>>
>> * Speed to access symbols.
>
> It needs the normal code to access the TLS struct / get the address of
> the TLS struct + on
Am Mon, 19 Mar 2012 16:14:36 +
schrieb Iain Buclaw :
>
> Initial things to think about on the top of my head:
>
> * Speed to access symbols.
It needs the normal code to access the TLS struct / get the address of
the TLS struct + one add instruction which adds the offset for the
specific va
On 3/18/2012 12:32 PM, Johannes Pfau wrote:
I thought about supporting emulated tls a little. The GCC emutls.c
implementation currently can't work with the gc, as every TLS variable
is allocated individually and therefore we don't have a contiguous
memory region for the gc. I think
On 2012-03-19 16:57, Johannes Pfau wrote:
Am Mon, 19 Mar 2012 10:40:25 +0100
schrieb Jacob Carlborg:
In general I was hoping that the work done by the dynamic loader to
setup TLS could be moved to druntime.
That'd be nice, but I think the runtime linker doesn't export all
necessary informat
On 19 March 2012 15:25, Johannes Pfau wrote:
> Am Mon, 19 Mar 2012 09:22:01 +
> schrieb Iain Buclaw :
>
>> On 19 March 2012 08:15, Johannes Pfau wrote:
>> >
>> > * Our own, emulated TLS support is implemented in GCC. This means
>> > it's also used in C, which is great. Also GCC's emulated tls
Am Mon, 19 Mar 2012 10:40:25 +0100
schrieb Jacob Carlborg :
> On 2012-03-19 09:15, Johannes Pfau wrote:
> > Am Sun, 18 Mar 2012 21:57:57 +0100
> > schrieb Jacob Carlborg:
> >
> >> On 2012-03-18 12:32, Johannes Pfau wrote:
> >>> I thought about supporti
Am Mon, 19 Mar 2012 09:22:01 +
schrieb Iain Buclaw :
> On 19 March 2012 08:15, Johannes Pfau wrote:
> >
> > * Our own, emulated TLS support is implemented in GCC. This means
> > it's also used in C, which is great. Also GCC's emulated tls needs
> > Â absolutely no special features in the runti
On 2012-03-19 09:17, Johannes Pfau wrote:
Am Sun, 18 Mar 2012 22:06:41 +0100
schrieb Jacob Carlborg:
Yes, but OSX still uses emulated tls. With the way dmd emulates TLS
it's possible to remove __tls_beg and __tls_end, but for native TLS
those symbols are still needed. However, as the runtime l
On 2012-03-19 09:15, Johannes Pfau wrote:
Am Sun, 18 Mar 2012 21:57:57 +0100
schrieb Jacob Carlborg:
On 2012-03-18 12:32, Johannes Pfau wrote:
I thought about supporting emulated tls a little. The GCC emutls.c
implementation currently can't work with the gc, as every TLS
variable is allo
On 19 March 2012 08:15, Johannes Pfau wrote:
> Am Sun, 18 Mar 2012 21:57:57 +0100
> schrieb Jacob Carlborg :
>
>> On 2012-03-18 12:32, Johannes Pfau wrote:
>> > I thought about supporting emulated tls a little. The GCC emutls.c
>> > implementation currently can
Am Sun, 18 Mar 2012 22:06:41 +0100
schrieb Jacob Carlborg :
> On 2012-03-18 19:39, Johannes Pfau wrote:
>
> > You mean getting rid of __tls_beg and __tls_end? I'd also like to
> > remove those, but:
>
> __tls_beg and __tls_end is not used by Mac OS X any more:
>
> https://github.com/D-Programmi
Am Sun, 18 Mar 2012 21:57:57 +0100
schrieb Jacob Carlborg :
> On 2012-03-18 12:32, Johannes Pfau wrote:
> > I thought about supporting emulated tls a little. The GCC emutls.c
> > implementation currently can't work with the gc, as every TLS
> > variable is allocated ind
On 2012-03-18 19:39, Johannes Pfau wrote:
You mean getting rid of __tls_beg and __tls_end? I'd also like to
remove those, but:
__tls_beg and __tls_end is not used by Mac OS X any more:
https://github.com/D-Programming-Language/druntime/commit/73cf2c150665cb17d9365a6e3d6cf144d76312d6
https://
On 2012-03-18 12:32, Johannes Pfau wrote:
I thought about supporting emulated tls a little. The GCC emutls.c
implementation currently can't work with the gc, as every TLS variable
is allocated individually and therefore we don't have a contiguous
memory region for the gc. I think the
Am Sun, 18 Mar 2012 12:21:51 +
schrieb Iain Buclaw :
> On 18 March 2012 11:32, Johannes Pfau wrote:
> > I thought about supporting emulated tls a little. The GCC emutls.c
> > implementation currently can't work with the gc, as every TLS
> > variable is allocated ind
On 18-03-2012 12:32, Johannes Pfau wrote:
I thought about supporting emulated tls a little. The GCC emutls.c
implementation currently can't work with the gc, as every TLS variable
is allocated individually and therefore we don't have a contiguous
memory region for the gc. I think the
On 18 March 2012 11:32, Johannes Pfau wrote:
> I thought about supporting emulated tls a little. The GCC emutls.c
> implementation currently can't work with the gc, as every TLS variable
> is allocated individually and therefore we don't have a contiguous
> memory region for
I thought about supporting emulated tls a little. The GCC emutls.c
implementation currently can't work with the gc, as every TLS variable
is allocated individually and therefore we don't have a contiguous
memory region for the gc. I think these are the possible solutions:
* Try to fix G
32 matches
Mail list logo
