If I had my way

[Martin Nowak]

On Tue, 13 Dec 2011 14:29:09 +0100, Jacob Carlborg <doob at me.com> wrote:

> On 2011-12-13 13:42, Martin Nowak wrote:
>> On Mon, 12 Dec 2011 12:31:44 +0100, Jacob Carlborg <doob at me.com> wrote:
>>
>>> On 2011-12-10 22:32, Walter Bright wrote:
>>>> On 12/10/2011 12:53 PM, maarten van damme wrote:
>>>>> Could also someone shed some light on creating shared library's on
>>>>> linux? there
>>>>> was some news about -fPIC beeing fixed but no real confirmation.
>>>>
>>>> Turns out there was a bug where EBX was not set correctly when  
>>>> calling a
>>>> function that existed in a shared library. This bug was fixed. So  
>>>> we're
>>>> ready to try again at creating a shared library with dmd.
>>>
>>> That's great to hear. We'll see how far we get this time.
>>>
>>
>> What's the state of the OSX dylib code in dmd and druntime?
>
> Most of the needed code is there but it's not "activated". I've been  
> trying to get it to work several times but it's always something that I  
> can't get to work.
>
> I currently have problems with TLS. Except from that it seems like it  
> works, but there are several improvements that could be made. I have
>
> I have a fork of druntime where you can see my progress, I've rewritten  
> what's already in druntime:  
> https://github.com/jacob-carlborg/druntime/tree/dylib
>
> What's needed or can be improved:
>
> * Cleanup module infos, exception handling tables and TLS when a dynamic  
> library is unloaded
>
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.



So currently I'm in favor of having to install a 'drt0.o' or so somewhere
in the library path and linking it into every executable/DSO.

> * A low level associative array and regular array that can be used  
> without having druntime full initialized
>
> I wrote to the DMD internals mailing list about this:  
> http://www.mail-archive.com/dmd-internals@puremagic.com/msg02701.html