RE: [PATCH 1/3] elf: Allow dlopen of filter object to work [BZ #16272]

[David Kilroy <David dot Kilroy at arm dot com>]

> Florian Weimer
> 
> * Szabolcs Nagy:
> 
> > the scenario is:
> >
> > libA.so and libB.so export a set of symbols.  this is abi and there
> > are multiple providers of libA.so and libB.so.
> >
> > one provider wants to have a single libinternal.so that defines all
> > the symbols of libA and libB as they share a lot of code.
> >
> > (1) having libA.so and libB.so as "wrapper libraries" around
> > libinternal.so with RTLD_NEXT would work, but that's less efficient
> > because of the extra indirection,
> 
> If libA.so and libB.so have libinternal.so as a DT_NEEDED dependency,
> you do not need to implement forwarding with RTLD_NEXT.

This is possible. You still need wrapper functions of some form. You
can try to avoid them by defining libA with no symbols and DT_NEEDED
libinternal.so, but then you need to link with -Wl,--copy-dt-needed
(BFD only) and end up with a dependency on libinternal.so rather than
libA.so.

> > (3) symlinking libA.so and libB.so to libinternal.so makes all
> symbols
> > visible when either of them is loaded, polluting the link namespace.
> 
> Filters do that as well.  There is no actual per-symbol run-time
> filtering implemented today, and it is unclear if Solaris implements it.

Agreed.
 
> > (libinternal.so is a video driver lib and libA, libB, .. are various
> > opengl libs with fixed abi)
> 
> Is there an expectation that libinternal interposes symbols in libA
> etc., perhaps with more efficient implementations?  And if not, a
> fallback implementation in libA etc. is used?  This is clearly not
> supported by the Solaris filter feature (as documented).

I'm not sure what you mean here. Libinternal.so is expected to supply the
implementations for the symbols in libA.so. Ideally we wouldn't pick up
other symbols from libinternal, but this is not an issue for us.
If libinternal.so were to use IFUNC relocations for libA's symbols, I
would hope it works, but I don't think that's being done.


Thanks,

Dave.