[Issue 11378] New: implicit runtime initialization/finalization is broken
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Tue Oct 29 07:04:35 PDT 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11378
Summary: implicit runtime initialization/finalization is broken
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: dll
Severity: regression
Priority: P2
Component: druntime
AssignedTo: nobody at puremagic.com
ReportedBy: code at dawg.eu
--- Comment #0 from Martin Nowak <code at dawg.eu> 2013-10-29 07:04:31 PDT ---
This change was introduced with
https://github.com/D-Programming-Language/druntime/pull/590 (commit
https://github.com/dawgfoto/druntime/commit/68eee299e28ee51421aac8fd5920edeb814c5b54).
It was added to perform automatic initialization/finalization when loading
shared libraries.
The change of the initialization order introduced some regressions (Bug 11149,
Bug 10976 and Bug 11309).
Furthermore the runtime initialization takes ownership of the main thread
(calls thread_attachThis) which may be unintended in a C executable that uses a
D library.
There are basically two ways to fix this.
A. Remove all implicit initialization/finalization.
All linked D libraries (including druntime) are initialized/finalized
by _d_run_main or by calling rt_init/rt_term for C executable.
Dynamically loaded shared libraries would need to be initialized after
loading and finalized before unloading. This required a ctor/dtor API in
druntime that can be called from within a shared library (might use the
return address to determine the calling DSO) to support D libraries in
C plugin frameworks that only allow predefined init/fini hooks.
We should also add an API that takes a library handle and runs ctors/dtors.
When moving the ctor/dtor calls out of libc's _d_dso_registry the calls need
to be synchronized.
B. Remove only implicit initialization/finalization of linked libraries.
All linked D libraries (including druntime) are initialized/finalized
by _d_run_main or by calling rt_init/rt_term for C executable.
Dynamically loaded shared libraries would still be initialized implicitly
(this includes calling rt_init/rt_term if it hasn't been called before and
implicitly attaching threads that load a D library).
The main difficulty here is to detect in _d_dso_registry whether the calling
DSO was linked or dynamically loaded.
I'm currently working on approach B because it avoids complicating the usage of
shared libraries.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list