On Tue, 13 Dec 2011 14:29:09 +0100, Jacob Carlborg <d...@me.com> wrote:
On 2011-12-13 13:42, Martin Nowak wrote:
On Mon, 12 Dec 2011 12:31:44 +0100, Jacob Carlborg <d...@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
