If I had my way

[Walter Bright]

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.