[Bug dynamic-link/27977] Unexpected behavior when using DT_FILTER

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27977

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to A.Dmitrovsky from comment #3)
> (In reply to Florian Weimer from comment #2)
> > This came up when we fixed bug 16272: DT_FILTER does not actually filter
> > anything (it just reorders name resolution), so the observed glibc behavior
> > is more or less as expected.
> 
> Could you please elaborate on "it just reorders name resolution"? What is
> the intended use case for the --filter option? 

DT_NEEDED puts the referenced object after the current object in the search
scope. DT_FILTER puts it before it. I believe this is the only difference in
the current glibc implementation. There is simply no filtering. It has been
this way since basically forever, so if we want to change DT_FILTER now, we
would have to make it dependent on some additional flag.

But to be clear, I do not see us fixing this issue any time soon. Ideally, the
change in lookup behavior would also be reflect in GDB, so that it can find the
same symbol the process uses at run time. And I do not see a way to implement a
properly filtering DT_FILTER without significant changes to the search scope
data structures.

Unfortunately, dlmopen is quite buggy, too, but maybe it will fit your use case
once we implement RTLD_SHARED. My hunch is that this will be ready before a
filtering DT_FILTER. (I assume RTLD_LOCAL is too limited for your use case.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.