Hi Johannes,

> Looks good to me, although ultimately Iain has to decide of course.

fine, thanks.  However, if we cannot find an acceptable solution for the
lack of dlpi_tls_modid, the patch isn't of much use:

* Solaris 11.5 will have all of dlpi_tls_modid and section bracketing.

* Solaris 11.4 has ld section bracketing, but might or might not get
  dlpi_tls_modid by a patch.

* Solaris 11.3 lacks ld section bracketing, won't get dlpi_tls_modid,
  and also needs this patch to link with -lsocket -lnsl separately:

        [build] Fix libgphobos linking on Solaris 11
        https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02248.html

> One nitpick: wouldn't you have to somehow mark __start/__stop _minfo as
> hidden? This is important in the case where you have multiple shared
> libraries and each library should have its own __start/__stop symbold to
> braket the library's minfo section.

Here's what I see in libgdruntime.so with various linkers/approaches for
minfo bracketing, using readelf -s libgdruntime.so|grep __start:

* gld 2.31 on x86_64-pc-linux-gnu (native gld section bracketing):

     2: 000000000012b770     0 NOTYPE  LOCAL  DEFAULT   26 __start_minfo
  1763: 000000000012b770     0 NOTYPE  LOCAL  DEFAULT   26 __start_minfo

* Solaris ld on i386-pc-solaris2.11 (Solaris 11.4 where ld supports
  section bracketing natively):

   136: 00147f40   836 OBJECT  LOCAL  HIDDEN    28 __start_minfo

* Solaris ld on i386-pc-solaris2.11 (Solaris 11.3 with drtstuff patch):

   150: 0014731c     0 OBJECT  LOCAL  HIDDEN    40 __start_minfo

I guess it's enough that the symbols are local, irrespective of visibility.

> Also 'if !DRUNTIME_OS_MINFO_BRACKETING' might be the wrong condition/name
> in Makefile.am if we add back support for per-module constructor-based
> module registration (instead of calling _d_dso_registry once per shared
> library passing all ModuleInfos in that library, call another hook
> _d_register_module once per module and pass only one ModuleInfo). But we
> can fix that if we ever need to add back support for that second
> approach. (If this startfile/endfile approach is portable enough, we may be
> able to avoid that).

It seemed natural to me to call the automake conditional similarly to
the variable set by the DRUNTIME_OS_MINFO_BRACKETING macro.  But I'm of
course open to other names, although it's probably best to only think
about renaming once section bracketing gets other uses.

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to