Am Tue, 17 Dec 2013 21:12:41 +0100
schrieb "David Nadlinger" <c...@klickverbot.at>:
> 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 implement module
> discovery for shared libraries? Would be a good idea to
> coordinate efforts and find a solution that works for all the
> backends, as Martin has been suggesting as well.
>
> David
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, we
should probably not forget the way C handles it's 'module
constructors', aka the '.ctors' / '.dtors' section.
They use linker scripts to make sure these sections are always
correctly bracketed by _start and _end symbols and we could do the same
for a '.moduleinfo' section and for the standard tls sections.
Here's the relevant part of a linker script:
------------------------
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
/* We don't want to include the .ctor section from
the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
------------------------
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 executable.
Ideally we'd get the default linker scripts changed, but that may take
some time if the binutils guys even agree. It's also possible to
1) give a linker script to ld to replace the default script (not so
good for us)
2) give ld a script to extend the default script (could work
for .moduleinfo section, I'm not sure about TLS)
One big problem is of course portability. But it seems such a solution
might be more portable than a solution relying on runtime
linkers (especially considering gcc already uses this internally for c++
support)
