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)