Re: RTLD_GLOBAL (& JIT inlining)

At Thu, 24 Jan 2019 01:02:14 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <24744(dot)1548309734(at)sss(dot)pgh(dot)pa(dot)us>
> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> > With the attached patch, external modules are loaded RTLD_LOCAL
> > by default. PG_MODULE_EXPORT_SYMBOL in a module source files let
> > it loaded RTLD_GLOBAL. I suppose this is the change with the
> > least impact on existing modules because I believe most of them
> > don't need to export symbols.
>
> This seems really hacky :-(
>
> In the PL cases, at least, it's not so much the PL itself that
> wants to export symbols as the underlying language library
> (libpython, libperl, etc). You're assuming that an action on
> the PL .so will propagate to the underlying language .so, which

(If I understand you correctly) I'm not assuming that the
propagation happens or even the contray. As can be seen from it
actually works, symbols of underlying libraries referred from
pl*.so are resoved using dependency list in pl*.so itself
independently of the RTLD flags given for it. The problem here is
while underlying language libraries cannot ferer symbols back in
the pl*.so when it is loaded with RTLD_LOCAL, RTLD_GLOBAL makes
some extensions unhappy.

I think that the assumption that RTLD_GLOBAL resolves all was
proved rather shaky. RTLD_DEEPBIND is not available on some
platforms so we need to choose between LOCAL and GLOBAL per
loading module.

> seems like a pretty shaky assumption. I wonder also whether
> closing and reopening the DL handle will really do anything
> at all for already-loaded libraries ...

internal_load_library() avoids duplicate loading so I believe it
cannot happen. Regarding duplicate dlopen, RTLD_GLOBAL just
promotes RTLD_LOCAL. In other words, the former wins. So it's not
a problem if the dlclose() there did nothing.

We could RTLD_NOLOAD for almost all platforms but win32 implement
needs additinal change to make work it as expected.

If you are saying hacky about that it uses only the symbol of
unused function, we can actually call it to get the flag.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center