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

[Florian Weimer <fweimer at redhat dot com>]

* David Kilroy:

>> The Solaris documentation does not mention symbol filtering (constraining
>> the set of exported symbols) at run time.  This kind of filtering is achieved at
>> run time because the link editor only looks at symbols in the filter and does
>> not consult the filtee.
>
> My assumption was that on Solaris only the symbols mentioned in the filter
> actually get bound at runtime. I haven't looked at what would have to be done
> to support that behaviour. I'm sounds non-trivial :)

I expected that based on the name of the feature, but the Solaris
documentation does not support that.  It's only clear that they filter
at link time.

>> On GNU, I think we support this via a linker script which specifies a link-time
>> object with a link-time ABI (typically a subset of the run-time ABI).  Therefore,
>> filter support is redundant.
>
> Do you have a link with some description? I've been digging around, and not
> come across separately specifying the link-time ABI.

Look at the contents for libc.so.  You can reference arbitrary DSOs
there, it doesn't have to be the implementation DSO that is used at run
time.

> I suspect that this wouldn't work in my use case though. External projects
> link against the filter object we produce, and don't know about the filtee
> (which is effectively an implementation detail). Different suppliers can also
> supply the library (which may or may not be a filter object), so having the
> external project link the library differently based on implementation is...
> suboptimal.

If you currently use a symbolic link for the .so link object, it should
be easy enough to replace that with the script.  If the link time DSO is
stored under its soname, then of course this does not work, but you
wouldn't be able to transparently inject the filter either, so that
doesn't seem to be your scenario.

I'm less clear how this all interacts with dlopen.  It seems that you
want a simple alias mechanism for dlopen.  In that case, a simple
symbolic link with the soname should work, and you don't need a separate
filter object, either.

Thanks,
Florian