On 2013-12-20 10:13, Johannes Pfau wrote:
Likely yes, that's why I said 'longterm' solution. You need to edit the
default linker script. Then there are 2 options: We can force certain
object files to be at the start or the end of the section. So we could
introduce dso_start.o and dso_end.o files
On Friday, 20 December 2013 at 14:55:46 UTC, Iain Buclaw wrote:
It should be possible if it's druntime handling all module
loading (if
you circumvent the module load handlers, don't expect it to work
properly).
eg:
loadModule(mod); // .ctors are ran and modules self register
themselves to 'mo
On 20 December 2013 13:06, David Nadlinger wrote:
> On Friday, 20 December 2013 at 10:54:56 UTC, Iain Buclaw wrote:
>>
>> As for module discovery, we already generate this in the GDC backend,
>> which makes it then the job of runtime to pick-up, sort and run the
>> ctors on all modules:
>>
>> @att
On Friday, 20 December 2013 at 10:54:56 UTC, Iain Buclaw wrote:
As for module discovery, we already generate this in the GDC
backend,
which makes it then the job of runtime to pick-up, sort and run
the
ctors on all modules:
@attribute("constructor")
void __modinit()
{
extern (C) __gshared Mo
On 2013-12-20 10:27, Johannes Pfau wrote:
Seems like the OSX linker is not based on the GNU linker and doesn't
have linker scripts either. There's some "sectorder" argument which
might be useful though.
It's probably BSD.
But relying on the runtime on OSX isn't bad as there's only one runtim
On 20 December 2013 07:40, Jacob Carlborg wrote:
> On 2013-12-19 20:51, Johannes Pfau wrote:
>
>> Sounds like that could work. But as the module section is a custom
>> section anyway we wouldn't have to replace/modify the default linker
>> script - we can pass a custom script to ld which just hand
Am Fri, 20 Dec 2013 08:43:12 +0100
schrieb Jacob Carlborg :
> On 2013-12-19 18:59, David Nadlinger wrote:
>
> > That is pretty much how it is done in DMD and LDC as well. The only
> > difference is that instead of modifying the linker scripts to
> > accommodate this, we emit the ModuleInfo refere
Am Fri, 20 Dec 2013 08:40:28 +0100
schrieb Jacob Carlborg :
> > I think asking the binutils maintainers to add __tdata_begin,
> > __tdata_end, __tbss_begin and __tbss_end markers to the tdata and
> > tbss sections would be a nice long-term solution, or is there some
> > issue with that?
>
> How d
On 2013-12-19 20:51, Johannes Pfau wrote:
Sounds like that could work. But as the module section is a custom
section anyway we wouldn't have to replace/modify the default linker
script - we can pass a custom script to ld which just handles the
".minfo" section. That should be just as portable as
On 2013-12-19 18:59, David Nadlinger wrote:
That is pretty much how it is done in DMD and LDC as well. The only
difference is that instead of modifying the linker scripts to
accommodate this, we emit the ModuleInfo references to custom sections.
The GNU toolchain (and we are in highly system-spe
Am Thu, 19 Dec 2013 18:59:42 +0100
schrieb "David Nadlinger" :
> Yes, this was the idea.
>
> > We can then access the bracket-symbols from a
> > module-constructor (or a
> > c-like .ctor constructor) in the library? So we'd have to add
> > drtbegin.o / drtend.o files to every d library or execut
On Wednesday, 18 December 2013 at 15:39:30 UTC, Johannes Pfau
wrote:
I hope I'm not talking bullshit here as I'm not 100% sure
what's meant
with 'module discovery'.
But if the question is how to get all ModuleInfos in a library,
[…]
Yes, this was the idea.
We can then access the bracket-sym
On 19 December 2013 16:34, Johannes Pfau wrote:
> Am Thu, 19 Dec 2013 15:39:28 +
> schrieb Iain Buclaw :
>
>> On 19 December 2013 11:47, Johannes Pfau wrote:
>> > Am Tue, 17 Dec 2013 18:48:38 +0100
>> > schrieb "Iain Buclaw" :
>> >
>>
>> It's compatible with libgcc emutls.
>
> Of course! I to
Am Thu, 19 Dec 2013 15:39:28 +
schrieb Iain Buclaw :
> On 19 December 2013 11:47, Johannes Pfau wrote:
> > Am Tue, 17 Dec 2013 18:48:38 +0100
> > schrieb "Iain Buclaw" :
> >
>
> It's compatible with libgcc emutls.
Of course! I totally missed the extern(C) in emutls.d. So emutls.d just
overw
On 19 December 2013 11:47, Johannes Pfau wrote:
> Am Tue, 17 Dec 2013 18:48:38 +0100
> schrieb "Iain Buclaw" :
>
>> Gthreads and Emulated TLS are now in GDC!!!
>>
>> https://github.com/D-Programming-GDC/GDC/commit/62554bfe1b35ee4f586634a76c65d83ebfa871ef
>>
>> The bug noted above still exists, how
Am Wed, 18 Dec 2013 17:36:53 +
schrieb Iain Buclaw :
> On 18 December 2013 15:39, Johannes Pfau wrote:
> > Am Tue, 17 Dec 2013 21:12:41 +0100
> > schrieb "David Nadlinger" :
> >
> >> On Tuesday, 17 December 2013 at 20:07:41 UTC, Iain Buclaw wrote:
> >> > The hidden subtext that you didn't und
Am Tue, 17 Dec 2013 18:48:38 +0100
schrieb "Iain Buclaw" :
> Gthreads and Emulated TLS are now in GDC!!!
>
> https://github.com/D-Programming-GDC/GDC/commit/62554bfe1b35ee4f586634a76c65d83ebfa871ef
>
> The bug noted above still exists, however what I am going to do
> is update and hook emulated
On 2013-12-18 18:36, Iain Buclaw wrote:
I'm not so sure about 'module discovery' either. At least, in
emulated TLS, it has a completely different concept - each thread has
a dynamically allocated range (effectively, a void**[] on the heap
that gets destroyed upon thread termination) which is sh
On 18 December 2013 15:39, Johannes Pfau wrote:
> Am Tue, 17 Dec 2013 21:12:41 +0100
> schrieb "David Nadlinger" :
>
>> On Tuesday, 17 December 2013 at 20:07:41 UTC, Iain Buclaw wrote:
>> > The hidden subtext that you didn't understand being, I'm
>> > holding back on Martin's patches for now.
>>
>
Am Tue, 17 Dec 2013 21:12:41 +0100
schrieb "David Nadlinger" :
> On Tuesday, 17 December 2013 at 20:07:41 UTC, Iain Buclaw wrote:
> > The hidden subtext that you didn't understand being, I'm
> > holding back on Martin's patches for now.
>
> That subtext isn't exactly hidden, given the first sent
On 17 December 2013 20:12, David Nadlinger wrote:
> On Tuesday, 17 December 2013 at 20:07:41 UTC, Iain Buclaw wrote:
>>
>> The hidden subtext that you didn't understand being, I'm holding back on
>> Martin's patches for now.
>
>
> That subtext isn't exactly hidden, given the first sentence in your
On 17 December 2013 19:08, Iain Buclaw wrote:
> On 17 December 2013 18:35, John Colvin wrote:
>> On Tuesday, 17 December 2013 at 17:48:40 UTC, Iain Buclaw wrote:
>>>
>>> Gthreads and Emulated TLS are now in GDC!!!
>>>
>>>
>>> https://github.com/D-Programming-GDC/GDC/commit/62554bfe1b35ee4f586634a
On 17 December 2013 18:35, John Colvin wrote:
> On Tuesday, 17 December 2013 at 17:48:40 UTC, Iain Buclaw wrote:
>>
>> Gthreads and Emulated TLS are now in GDC!!!
>>
>>
>> https://github.com/D-Programming-GDC/GDC/commit/62554bfe1b35ee4f586634a76c65d83ebfa871ef
>>
>> The bug noted above still exist
On Tuesday, 17 December 2013 at 20:07:41 UTC, Iain Buclaw wrote:
The hidden subtext that you didn't understand being, I'm
holding back on Martin's patches for now.
That subtext isn't exactly hidden, given the first sentence in
your first post. ;)
Do you have a plan yet regarding how to imple
On 17 December 2013 19:34, David Nadlinger wrote:
> On Tuesday, 17 December 2013 at 19:09:31 UTC, Iain Buclaw wrote:
>>
>> Native TLS support on linux will have to wait a while before I get
>> that working... (but you could always build with --disable-tls)
>
>
> Wait, so GDC doesn't (entirely) sup
On Tuesday, 17 December 2013 at 19:09:31 UTC, Iain Buclaw wrote:
Native TLS support on linux will have to wait a while before I
get
that working... (but you could always build with --disable-tls)
Wait, so GDC doesn't (entirely) support native TLS on Linux?! Or
are you just talking about share
On Tuesday, 17 December 2013 at 17:48:40 UTC, Iain Buclaw wrote:
Gthreads and Emulated TLS are now in GDC!!!
https://github.com/D-Programming-GDC/GDC/commit/62554bfe1b35ee4f586634a76c65d83ebfa871ef
The bug noted above still exists, however what I am going to do
is update and hook emulated TLS
Gthreads and Emulated TLS are now in GDC!!!
https://github.com/D-Programming-GDC/GDC/commit/62554bfe1b35ee4f586634a76c65d83ebfa871ef
The bug noted above still exists, however what I am going to do
is update and hook emulated TLS into the GC.
On Monday, 16 December 2013 at 15:46:59 UTC, Iain Buclaw wrote:
We really need to understand this problem first before can
start merging Martin's shared library work into gdc.
Running testsuite:
=== gdc Summary ===
# of expected passes13841
# of unexpected failures1
FAIL:
We really need to understand this problem first before can start
merging Martin's shared library work into gdc.
Running testsuite:
=== gdc Summary ===
# of expected passes13841
# of unexpected failures1
FAIL: runnable/testaa.d execution test
Running unittests:
./libdrun
30 matches
Mail list logo
