On Tuesday, 4 July 2017 at 22:45:45 UTC, Iain Buclaw wrote:
The ARMs look good. I'm not sure about the X86_64: The 'VPS'
are
'shared' but I haven't found any information what exactly they
share
(shared cores?). Additionally some 2016 reports say the VPS use
Intel Atom cores and only the more ex
On Saturday, 7 March 2015 at 23:40:38 UTC, Iain Buclaw wrote:
Hi,
Some aspects of gdcproject.org will be down for the next few
hours. Should be all back up Sunday morning-ish time. This is
due to work being done by the host providers that requires a
reboot of the VM at a time when I will no
On Saturday, 20 October 2012 at 15:27:34 UTC, Timo Sintonen wrote:
STM32F0 may be too small.
Yeah probably. Are there any patches required to build a
cross-gdc?
On Thu, 18 Oct 2012 13:36:45 +0200, Timo Sintonen
wrote:
I have written programs with C for Arm Cortex controller boards. I think
that D might be an interesting nut simple enough oo language. So far I
have a working gdc for my target, but I can not compile the runtime
library because of
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 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.
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/
11 matches
Mail list logo
