[D-runtime] druntime ModuleInfo discovery without bracketing segments

[Martin Nowak]

On 06/14/2013 02:58 PM, David Nadlinger wrote:
> Hi Martin,
Sorry for the delay, I got pretty busy recently.
> I'm working on the LDC 2.063 merge right now, and it would obviosuly
> be nice to finally support shared libraries in LDC as well (PIC/shared
> object codegen works since ages ago, but runtime support was missing
> so far).
>
> However, I would like to avoid the use of bracketing sections/symbols
> for locating the ModuleInfos of all the linked modules (we don't need
> to handle EH tables anyway). While it is certainly possible to crack
> open the default LLVM object file emission pipeline and directly write
> out some custom data in an object file format dependent way, this
> would also mean that we cannot use the standard LLVM tools for
> generating object files from bitcode (LLVM IR) anymore, which would be
> quite annoying for tooling.
>
> Thus, I thought about using a scheme where there is one global (C
> runtime) ctor per module just like there is in the old one. Instead of
> setting up the _Dmodule_ref chain directly, it would call the
> equivalent of _d_dso_registry. If a DSO info record (struct DSO in
> sections_linux) has not been initialized for the given image yet, the
> function would set it up, and in any case add the passed ModuleInfo*
> to a pointer array in the record.
I don't think bracketing section are the problem (except for the ld bugs 
in older OSX versions).
In fact they come with two benefits.
There is only a single call that contains all information about a shared 
library at once.
Because the call is the only one you can use it to perform initialization.
When you have one call per module you first have to gather all 
information and can
only perform initialization when it's complete.
So this performs worse and is annoying to implement.

The basic problem to solve is that _minfo* sections must be merged by 
the linker but _minfo_beg and _minfo_end must not be be external symbols 
as the executable would superimpose them.
This is currently done with section groups of internal symbols.
I recently had the idea that it should also work with hidden external 
symbols but I still have to verify that.
If it works we could move the functionality into the glue layer so that 
it can hopefully be reused by GDC and LDC.
Otherwise we could also try to add support for section groups and 
internal symbols in the glue layer but that might be a lot of work.

Best,
Martin