Re: CPython vs libstdc++

[Carlos O'Donell <carlos at redhat dot com>]

On 7/11/19 12:50 PM, Szabolcs Nagy wrote:
> they don't use dlmopen, but dlopen with RTLD_LOCAL
> (well they only pass RTLD_NOW by default but that means local,
> you can check/change this by sys.getdlopenflags() and sys.set...)

You can have further dlopen's with RTLD_GLOBAL the promote the
object to global scope and so this is a mess, and I think I've
already mentioned this to upstream python developers at least
once. This issue rings a bell. We've discussed python plugins
and C++ in the past.

The current libstdc++ is not designed to be loaded into the
process image with RTLD_LOCAL, and libstdc++ uses dl_iterate_phdr()
to look for loaded objects and use them during unwinding, and this
is going to use the binaries object scope, not the local scope
created by RTLD_LOCAL.

My opinion is that if you want to use C++ with python plugins, then
the python interpreter needs to be linked against one libstdc++ and
then all plugins can use C/C++ for bindings, but I don't know if that
would fly.

> > me, because I do know that both g++-compiled C++ in general, and
> > critical bits of libstdc++ in particular (e.g. the exception unwinder)
> > rely on certain data objects being unique within the entire address
> > space (process).
> >
> > On the hypothesis that the problem is caused by two copies of
> > libstdc++.so and/or libgcc_s.so being loaded into a single address
> > space, which cannot reasonably be made to work, even if they're the
> > exact same version: we need some way of loading a shared object such
> > that only one copy will be loaded, and reused for each ELF namespace
> > that needs it.  As far as I can tell, this is currently not possible.
> > Ideally the trigger for this behavior would be an annotation on each
> > shared object that needs it, rather than requiring all programs that
> > use ELF namespaces to be aware of the issue; however, we might _also_
> > want a way for a program that uses ELF namespaces to request this
> > behavior, in case it's trying to support old libraries that don't have
> > the annotation even though they ought to.
>
> there is known conflict between RTLD_LOCAL and c++ odr requirement
> for 'vague linkage' objects, the gnu toolchain solution using
> STB_GNU_UNIQUE binding may have issues (and that can be turned
> off in gcc/gold so we would need to know what toolchain were used
> for those python modules)

Correct, RTLD_LOCAL is a thing that doesn't make sense for C++, and
so the use of STB_GNU_UNIQUE is to promote such symbols to global
scope.

You have to understand that for C++ some things will violate your
expectations of isolation.

You really need to use dlmopen here, and that has lots of bugs too
because we only implement what is barely required for LD_AUDIT.
Though we have RFC patches to make it better.

> it's also possible that some modules were built with -static-libstdc++
> you will have to dig further.

That would be a possibility, and I'm not sure what we support there.
If the two plugins didn't pass relevant objects, then it might work, but
again I don't know how the unwinder works with -static-libstdc++ in
effect.

--
Cheers,
Carlos.