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:
> 
> >> Florian Weimer
> >> * 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.
> >
> > [I just wanted to respond to this part of your email here. I'll
> > respond to the rest via Szabolcs email.]
> >
> > The web page does say "The runtime linker uses the filtee to resolve
> > any symbols defined by filter.so.1. If the filtee is not found, or a
> > filter symbol is not found in the filtee, the filter is skipped for
> > this symbol lookup."
> 
> It says “not found in the filtee”.  I think this means that the filter is
> never used for symbol lookup (something we do not implement in glibc), not
> that the symbol set of the filtee is restricted to that of the filter (not
> implemented either).  It is possible that there was a typo here in and the
> roles of filter and filtee are swapped in this documentation paragraph,
> though.

It makes sense to me. I agree that the filter is never used for symbol lookup.

filter.so.1, has symbol a(), b() and has DT_FILTER filtee.so.1
filtee.so.1, has symbols a(), c()

The first sentence says that the symbols defined in filter.so.1 would be
resolved from filtee.so.1. So the runtime linker should look for a() and b()
in filtee.so.1.

The second sentence deals with b(), which is not in the filtee. To me it says
that b() shouldn't resolve to the filters implementation, and therefore b()
has to come from later in the search path.

Conversely an auxiliary object _would_ resolve b() to the auxiliary library
implementation. "If this filtee is found, the runtime linker uses the filtee
to resolve any symbols defined by filter.so.1. If the filtee is not found, or
a symbol from the filter is not found in the filtee, then the original symbol
within the filter is used."

I think this text for the auxiliary object is a little clearer.


Regards,

Dave.