Hi Rainer,
I'd recommend not using such a workaround:
This means getTLSRange will always return an empty range, but the GC
uses this to scan TLS memory. This means a GC collection can delete
objects which are still pointed to from TLS. This leads to hard to debug
errors, and if I remember correctly, the testsuite will not catch these
errors. I think we have code in phobos though which references objects
only from TLS and this will break after a GC collection.
I just noticed we now have similar code in upstream druntime for uclibc
though so I also posted a comment there:
https://github.com/dlang/druntime/pull/2157
I'm not sure what's a good solution here. EmuTLS has got the same
problem, but I'll post a RFC patch next weekend which would allow to
scan the emuTLS memory. If we somehow make that work, I'd recommend to
use emuTLS instead of native TLS if there's no way to scan the native TLS*.
FYI Martin Nowak(in CC) wrote most of the original code for rt.sections
so he's the expert we'd have to ask.
* Maybe we could implement a more runtime-independent approach to scan
native TLS?
1) We somehow need to bracket the TLS section (it would have to be
per-shared-library though, we basically need thread-local, hidden
__start_tls and __stop_tls symbols).
2) We need to emit a hidden _dso_scan_tls function into each D library.
A pointer to this DSO specific function then has to be passed in
CompilerDSOData to _d_dso_registry.
3) tlsRange has to forward to the correct, DSO specific _dso_scan_tls.
2 and 3 are easy but I'm not sure if we can do 1.
Best regards,
Johannes
Am 29.01.19 um 11:52 schrieb Rainer Orth:
Before Solaris 11.5, struct dl_phdr_info lacked the dlpi_tls_modid
member. While the support might be backported to Solaris 11.4, it
certainly won't to previous Solaris releases. To work around this, I've
used the following patch. Again, it's pretty straightforward.
Point of note:
* On Solaris, FreeBSD and NetBSD, dl_phdr_info is always visible in
<link.h>, while on Linux one needs to define _GNU_SOURCE.
AC_USE_SYSTEM_EXTENSION takes care of this, but needs to be called
early (i.e. not in DRUNTIME_OS_DLPI_TLS_MODID) to avoid an autoconf
warning:
configure.ac:129: warning: AC_COMPILE_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
m4/druntime/os.m4:190: DRUNTIME_OS_DLPI_TLS_MODID is expanded from...
configure.ac:129: the top level
Tested on i386-pc-solaris2.11 (Solaris 11.4) and x86_64-pc-linux-gnu.
Not unexpectedly, there are a couple of regressions compared to the
Solaris 11.5/x86 results:
+FAIL: gdc.test/runnable/testaa.d execution test
+FAIL: gdc.test/runnable/testaa.d -fPIC execution test
+FAIL: gdc.test/runnable/testaa.d -fPIC -shared-libphobos execution test
+FAIL: gdc.test/runnable/testaa.d -shared-libphobos execution test
32 and 64-bit
+FAIL: gdc.test/runnable/xtest55.d execution test
+FAIL: gdc.test/runnable/xtest55.d -shared-libphobos execution test
64-bit only
+FAIL: libphobos.shared/link_linkdep.d -I/vol/gcc/src/hg/trunk/local/libphobos/t
estsuite/libphobos.shared liblinkdep.so lib.so -shared-libphobos execution test
+FAIL: libphobos.shared/load_linkdep.d -shared-libphobos -ldl execution test
+FAIL: libphobos.shared/load_loaddep.d -shared-libphobos -ldl execution test
+FAIL: libphobos.shared/linkDR.c -shared-libphobos -ldl -pthread execution test
+FAIL: libphobos.shared/host.c -ldl -pthread execution test
+FAIL: libphobos.shared/loadDR.c -ldl -pthread -g execution test
32 and 64-bit
+FAIL: libphobos.shared/link.d
-I/vol/gcc/src/hg/trunk/local/libphobos/testsuite/libphobos.shared lib.so
-shared-libphobos execution test
64-bit only
I haven't looked much closer yet, just posting this to see if anything
along those lines could be acceptable at all.
Rainer
