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

[David Kilroy <David.Kilroy@arm.com>]

> Florian Weimer
> 
> * David Kilroy:
> 
> >> 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.
> 
> Ahh, thanks for explaining it to me.  So this is the part that
> specifies that filters do actually filtering.
> 
> As I said, I think glibc does not implement this, and I'm not sure if
> implementing it would break your use case (hence my question about
> interposition and default implementations).

Agreed. Glad I could clear up that point :)

If glibc did implement something closer to the Solaris spec, I would
expect what we're doing to continue working. But the current
implementation is sufficient for our purposes (bar the dlopen behaviour)


Thanks,

Dave.