If I had my way

[Martin Nowak]

On Tue, 13 Dec 2011 20:14:58 +0100, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 12/13/2011 6:15 AM, Martin Nowak wrote:
>> TLS is not too difficult. We can either use bracketed sections again or
>> let the compiler emit small thunks that fetch the complete TLS section  
>> for
>> a executable/DSO. The important point is that fetching the TLS  
>> addresses must
>> be done for each thread and from a local function within each DSO.
>> people.redhat.com/drepper/tls.pdf
>> My current approach is to register callbacks, and let the threads update
>> their ranges before GC.
>> Not sure, but it will probably causes eagerly allocation of the TLS  
>> blocks.
>>
>> Some similar issues happen with the other section brackets (.deh,  
>> .minfo).
>> We need local symbols as brackets not global ones as they would collide.
>>
>> I've tried several approaches.
>>
>> o Using a linker script with a recent binutils, add needed d sections
>> and use PROVIDE_HIDDEN to bracket them. Then it's only a matter
>> of adding constructor/destructor routines that register with druntime.
>>
>> It's not too feasible as newer binutils are default on linux only
>> and distributing linker scripts is not too nice either.
>>
>> o Create a C module similar to crt0.o that creates d sections and  
>> bracketing
>> symbols. Add constructor/destructor to register with druntime.
>>
>> The object file needs to be the first when linking, but the linker
>> can merge sections, thus there is only one registration per
>> executable/shared library.
>>
>> o Let the compiler generate a constructor/destructor for executables
>> and shared libraries. The object would also need to get linked first.
>>
>> This is less transparent than the 2nd option without much benefit.
>>
>> o Generate registration routines per object file. No bracketed sections.
>
> If the compiler generated static constructors and destructors ala C++  
> that would then be used to register the sections, that could hook into  
> the existing C++ support code and not require special linker scripts and  
> special object files.

I partly agree and will give that approach another try.
The huge drawback is that a shared library is self-contained w.r.t.
module construction, TLS and EH. When doing this on a per object base
the overhead increases with the number of linked objects and guaranteeing
ordered initialization becomes non-trivial.