From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 2D7FF38515F3; Thu, 10 Jun 2021 10:16:25 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2D7FF38515F3
From: "tdiff at yandex dot ru" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/27977] New: Unexpected behavior when using DT_FILTER
Date: Thu, 10 Jun 2021 10:16:24 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.34
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tdiff at yandex dot ru
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
 attachments.created
Message-ID: <bug-27977-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: glibc-bugs@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Glibc-bugs mailing list <glibc-bugs.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/glibc-bugs/>
List-Help: <mailto:glibc-bugs-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jun 2021 10:16:25 -0000

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

            Bug ID: 27977
           Summary: Unexpected behavior when using DT_FILTER
           Product: glibc
           Version: 2.34
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: tdiff at yandex dot ru
  Target Milestone: ---

Created attachment 13489
  --> https://sourceware.org/bugzilla/attachment.cgi?id=3D13489&action=3Ded=
it
Problem repro

Hi,

I am trying to use DT_FILTER to hide conflicting symbol implementation from=
 one
of two libraries linked into the main executable.

In the attached example I have following setup:
lib1.so: func1(), func2()
lib2.so: func1(), func3()
lib2f.so: func3() //< this is a filter for lib2.so
main(): calls func1(), func2(), func3().

lib2f.so and lib1.so are passed to ld in the following order:
  gcc main.c -L. -l2f -l1 -o $@

Expected:
main calls func1() from lib1.so

Actual:
main calls func1() from lib2.so

Reasoning:
>>From man ld:
       -F name
       --filter=3Dname
           ...=20
           If you later link a program against this filter object, then,
           when you run the program, the dynamic linker will see the
           DT_FILTER field.  The dynamic linker will resolve symbols
           according to the symbol table of the filter object as usual,
           but it will actually link to the definitions found in the
           shared object name. Thus the filter object can be used to
           select a subset of the symbols provided by the object name.

This clearly refers to runtime linker and mentions that dynsym of filter.so
should be used for symbol lookup. However, it looks like runtime liker does=
 not
respect filter object.

I observe same behavior on glibc 1.17 @ Suse and 1.34 @ Ubuntu so looks lik=
e it
is not a distro-specific issue.

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