On 20 December 2013 07:40, Jacob Carlborg <d...@me.com> 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 handles the
>> ".minfo" section. That should be just as portable as relying on the
>> "don't reorder sections" behavior: Works everywhere where GNU Binutils
>> LD/GOLD are used. (Emitting 3 sections is a clever trick, but it feels
>> like a hack imho. I'm also not sure if we can control the order in
>> which sections are emitted in GCC)
>
>
> The trick with brackting sections doesn't work on Mac OS X. DMD had some
> problems with that. It basically broke on every new major release of Mac OS
> X, the linker changed all the time. If I recall correctly it either removed
> the empty sections or reordered the sections.
>
>
If using GDC on OSX, then you be going through the emutls module I've
got set-up.
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 ModuleReference* _Dmodule_ref;
static private ModuleReference __mymod = ModuleReference(null, minfo);
__mymod.next = _Dmodule_ref;
_Dmodule_ref = &__mymod;
}
Unless I'm missing something in how module discovery is supposed to
work, this could be instead amended to:
@attribute("constructor")
void __modinit()
{
extern (C) void __register_module(ModuleInfo *);
__register_module(&minfo);
}
So that any lazily loaded modules would be recorded to an existing
list and trigger a run-once ctor run.
Regards
Iain
