If I had my way

[Jacob Carlborg]

On 2011-12-14 11:17, Martin Nowak wrote:
> 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.

I don't think this is necessary to support dynamic libraries on Mac OS 
X. I think and hoping _dyld_register_func_for_add_image is sufficient.

-- 
/Jacob Carlborg