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
> * David Kilroy:
> 
> [Changes related to inserting the filtee before the filter]

> David, have you ever used filters on Solaris?  Can you comment on the
> expected behavior for them?

Unfortunately, I don't have access to Solaris.

I've commented below.

> >>I have much more trouble ascertaining whether this change is correct.
> >>Are we certain that new->l_initfini is not a subset of the maps that
> >>have been loaded?
> >
> > That is something I'm not sure about (yet). I'll look into this
> > further. My reasoning for switching to using l_initfini was that the
> > filtee's constructors were crashing, and clearly anything that needed
> > initialisation ought to be relocated first.
> 
> In an off-list discussion, Carlos also had some concerns about the state of
> filter support.  Based on the Solaris documentation,
> 
>   <https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter4-4.html>
> 
> it seems to me that filters are mostly a link editor feature.  Sorting the filtee
> prior to the filter appears to be the right thing to do.

This is the documentation I've been looking at for filter objects.

> However, what seems to be missing currently is ignoring the filter during
> symbol binding.  I think if the filter contains symbols that are not present in
> the filtee, it is possible to bind them.  That does not seem to match the
> documented Solaris behavior.

That's my understanding. To get the Solaris behaviour in this case we could
remove the filter from search (and init) paths - but only for filter objects
though, as auxiliary objects may want to bind some symbols in the filter.

> 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 :)

This would matter if the filtee exported a symbol that the application actually
wanted to pick up from a library later on the search path. As far as I'm aware
this doesn't occur for us, so the lack of support is not a problem.

> 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.

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.



Regards,

Dave.