From nobody Sat Apr 19 09:39:27 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zfmmx609Jz5t66p for ; Sat, 19 Apr 2025 09:39:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zfmmx3CfZz3KcM; Sat, 19 Apr 2025 09:39:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745055569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=mCOzrtx2tYm2qta4wXEss21i5megjwLSYq6KbWlaZ/E=; b=wlzI78GXL/J/7G5rnLcvhzgZHTqdGWN97403n97I0mmxvpW0pTCvG3OmVZ0zkEJkFWVGXq s5EmCp5U6RqUu/EgmJRIvU8ZpNVQdlY2d6pZRbF0YRqTdBcCUKllX5hbH57kobkP8FQ81r GZL2hsBnBIrDI1t2jki9c8auPQDG8XJ6FIMYuC368IV+G0njUgjp4zlVoZs8uu8GAJX1mD TH6o3ik06rqOXXOe5MVGpLiJem1gvIAOzk3IRP3zHFaVLWWYLRIzNOmO1WNpY+ybHlDHQh ArDFri5Ibo9jJaNwk0I4PKVCugJqtmQ8fQEQESKKTCe6yGreBGSPBwf5IhRmqA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745055569; a=rsa-sha256; cv=none; b=f6YyHKEgbDazypoY3xhAtNAbEX5kLSRD0tIC6oTVnSfraHl1uDoXIWAQEmrkwGjiDBm57n mo9VIJY8QeCc8X8rQG9iMD1nEfOQGhmiUEFg0UztkT3echy29iheVmfMDbvEVc+mjJ2Map ET4peELf5rTG1EVuK0p90HMXvHHqIuSNJubuBfFLmJpx269moLW31dp0i6fQQpGgPUFKhF 4P/azgy0+qv1wDBGX24vDtlKb9VIbXAWpY7UXXIsbQeCDpkBP6+2yVDPwxCKpBbRiDMOa2 5W+DL1RHzAIHOmSizhldkhE+jpqKomcwXgr0RnL6Meo+8lZ9icy4sK53eGmuoA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745055569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=mCOzrtx2tYm2qta4wXEss21i5megjwLSYq6KbWlaZ/E=; b=tAAIOlP4ZL6amy7A2RzbkK+uKx/vqyW7uRdN3mgkKvHGHo6ek3rtKuz9dKZHqFtk81rEvV 2uEeY299GhG9nqjYRsevweZNvwWZl6WGlFX42YcEnrVDpHLqRsV4BznS0R5h5dtQld2V8a SgeQZSB6aVdtpfh1okXqJYo9g56B74aCX+Hts2sNEuz8aCodBr69e3YngdzYD1PmeUnmel VnDOoicgq0lNMMioSsKUmgpCryKsyKxi62ePEzlmKiAbIVD/rCwbkVhFwlVRGzKRQodeC0 hbKrTfc3rzauUNj+2G7AjLPpzyNMh9AKKdvBkXBQqdJWvIFfI4PQqLb3EhAqug== Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zfmmw6sDGzByP; Sat, 19 Apr 2025 09:39:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Sat, 19 Apr 2025 12:39:27 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RTLD_DEEPBIND question From: Andriy Gapon To: Konstantin Belousov Cc: FreeBSD Current References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> Content-Language: en-US Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 19/04/2025 12:25, Andriy Gapon wrote: > On 19/04/2025 02:41, Konstantin Belousov wrote: >> Could it be that the module is linked to the main binary? > > It does not appear to be so. > The binary: > $ ldd /usr/local/bin/mdb > /usr/local/bin/mdb: >         libncursesw.so.9 => /lib/libncursesw.so.9 (0xbf191c93000) >         libtinfow.so.9 => /lib/libtinfow.so.9 (0xbf190b45000) >         libkvm.so.7 => /lib/libkvm.so.7 (0xbf192a74000) >         libproc.so.5 => /usr/lib/libproc.so.5 (0xbf1930f4000) >         librtld_db.so.2 => /usr/lib/librtld_db.so.2 (0xbf19382d000) >         libctf.so.2 => /lib/libctf.so.2 (0xbf19466c000) >         libumem.so.2 => /lib/libumem.so.2 (0xbf194b0a000) >         libelf.so.2 => /lib/libelf.so.2 (0xbf194eb6000) >         libutil.so.9 => /lib/libutil.so.9 (0xbf19550c000) >         libz.so.6 => /lib/libz.so.6 (0xbf195875000) >         libc.so.7 => /lib/libc.so.7 (0xbf1961fb000) >         libcxxrt.so.1 => /lib/libcxxrt.so.1 (0xbf197493000) >         libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0xbf197753000) >         libspl.so.2 => /lib/libspl.so.2 (0xbf197f77000) >         libsys.so.7 => /lib/libsys.so.7 (0xbf198bc6000) >         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xbf199475000) >         [vdso] (0xbf1902db000) > > The module: > $ ldd /usr/local/lib/mdb/kvm/amd64/dtrace.so > /usr/local/lib/mdb/kvm/amd64/dtrace.so: >         libdtrace.so.2 => /lib/libdtrace.so.2 (0x24d1702c8000) >         libm.so.5 => /lib/libm.so.5 (0x24d1711c3000) >         libc.so.7 => /lib/libc.so.7 (0x24d16cfbb000) >         libctf.so.2 => /lib/libctf.so.2 (0x24d16eee6000) >         libelf.so.2 => /lib/libelf.so.2 (0x24d16c13e000) >         libproc.so.5 => /usr/lib/libproc.so.5 (0x24d172085000) >         librtld_db.so.2 => /usr/lib/librtld_db.so.2 (0x24d173d46000) >         libxo.so.0 => /lib/libxo.so.0 (0x24d172b1d000) >         libthr.so.3 => /lib/libthr.so.3 (0x24d17411c000) >         libspl.so.2 => /lib/libspl.so.2 (0x24d174e8d000) >         libz.so.6 => /lib/libz.so.6 (0x24d173a38000) >         libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x24d17635a000) >         libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x24d175fb8000) >         libutil.so.9 => /lib/libutil.so.9 (0x24d176864000) >         libsys.so.7 => /lib/libsys.so.7 (0x24d16df97000) >         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x24d17567f000) >         libkvm.so.7 => /lib/libkvm.so.7 (0x24d177768000) > >> RTLD_DEEPBIND works by first iterating over all (recursive) DT_NEEEDED >> object for the object where the symbol is resolved, then by looking at >> the global list of loaded objects. >> Non-deepbind resolution is performed by looking at the global list. >> >> You can see it in the rtld.c:symlook_default(). From a quick look at the code, should we try to resolve the symbol in refobj itself when it's marked with deepbind? >> Also it might be useful to set LD_DEBUG=1 and read the debugging output >> from rtld. > Thank you for reminding me about LD_DEBUG.I can provide the full output I got > with it, but here are some interesting bits. > BTW, I tried both RTLD_NOW and RTLD_LAZY, just in case. > There was no difference in behavior. > This output is when using RTLD_LAZY. > > dlopen_object name "/usr/local/lib/mdb/kvm/amd64/dtrace.so" fd -1 refobj "/usr/ > local/bin/mdb" lo_flags 0x82 mode 0x1 > > lm_find("/usr/local/bin/mdb", "/usr/local/lib/mdb/kvm/amd64/dtrace.so") > lml_find(0x2fe0e1004198, "/usr/local/lib/mdb/kvm/amd64/dtrace.so") > loading "/usr/local/lib/mdb/kvm/amd64/dtrace.so" > /usr/local/lib/mdb/kvm/amd64/dtrace.so valid_hash_sysv 1 valid_hash_gnu 1 > dynsymcount 75 >   0x1b24f41bf000 .. 0x1b24f41cdfff: /usr/local/lib/mdb/kvm/amd64/dtrace.so > lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "libdtrace.so.2") > lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") > lml_find(0x2fe0e1004198, "libdtrace.so.2") >  Searching for "libdtrace.so.2" > search_library_pathfds('libdtrace.so.2', '(null)', fdp) > lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "/lib") > lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") >   Trying "/lib/libdtrace.so.2" >   Opened "/lib/libdtrace.so.2", fd 51 > loading "/lib/libdtrace.so.2" > /lib/libdtrace.so.2 valid_hash_sysv 1 valid_hash_gnu 1 dynsymcount 810 >   0x1b24efbcc000 .. 0x1b24efc7afff: /lib/libdtrace.so.2 > lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "libm.so.5") > lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") > lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "/lib") > lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") > lm_find("/lib/libdtrace.so.2", "libxo.so.0") > lmp_find("/lib/libdtrace.so.2") > lm_find("/lib/libdtrace.so.2", "/lib") > lmp_find("/lib/libdtrace.so.2") > lm_find("/lib/libdtrace.so.2", "libthr.so.3") > lmp_find("/lib/libdtrace.so.2") > lm_find("/lib/libdtrace.so.2", "/lib") > lmp_find("/lib/libdtrace.so.2") > relocating "/usr/local/lib/mdb/kvm/amd64/dtrace.so" > relocating "/lib/libdtrace.so.2" > calling init function for /lib/libdtrace.so.2 at 0x1b24efc689cc > calling init function for /lib/libdtrace.so.2 at 0x1b24efc179a0 > calling init function for /lib/libdtrace.so.2 at 0x1b24efc420d0 > "getenv" in "libdtrace.so.2" ==> 0x1b24edfea3f0 in "libc.so.7" > "rd_init" in "libdtrace.so.2" ==> 0x1b24e9dd07d0 in "librtld_db.so.2" > calling init function for /usr/local/lib/mdb/kvm/amd64/dtrace.so at 0x1b24f41cacac > calling init function for /usr/local/lib/mdb/kvm/amd64/dtrace.so at > 0x1b24f41c49e0So far so good, I think.The module got loaded, libdtrace got > loaded as its dependency and then some dependencies Then I executed a command > that made a call into dtrace.so module. > "mdb_getopts" in "dtrace.so" ==> 0x1b1cc46b6760 in "mdb" > "mdb_readvar" in "dtrace.so" ==> 0x1b1cc46db470 in "mdb" > "mdb_vread" in "dtrace.so" ==> 0x1b1cc46db040 in "mdb" > "memset" in "dtrace.so" ==> 0x1b24edfde8f0 in "libc.so.7" > "dtrace_vopen" in "dtrace.so" ==> 0x1b24efc43320 in "libdtrace.so.2" > "elf_version" in "libdtrace.so.2" ==> 0x1b24eafbefe0 in "libelf.so.2" > "calloc" in "libdtrace.so.2" ==> 0x1b24edffd0a0 in "libc.so.7" > "dt_proc_init" in "libdtrace.so.2" ==> 0x1b24efc5be40 in "libdtrace.so.2" > "dt_zalloc" in "libdtrace.so.2" ==> 0x1b24efc61df0 in "libdtrace.so.2" > "pthread_mutex_init" in "libdtrace.so.2" ==> 0x1b24edf165d0 in "libc.so.7" > "pthread_cond_init" in "libdtrace.so.2" ==> 0x1b24edf163d0 in "libc.so.7" > "strdup" in "libdtrace.so.2" ==> 0x1b1cc46ed5a0 in "mdb" > "malloc" in "libdtrace.so.2" ==> 0x1b24edffc370 in "libc.so.7" > > (lots of output skipped) > > "dt_idstack_push" in "libdtrace.so.2" ==> 0x1b24efc360c0 in "libdtrace.so.2" > "dt_irlist_create" in "libdtrace.so.2" ==> 0x1b24efc1b240 in "libdtrace.so.2" > "yyinit" in "libdtrace.so.2" ==> 0x1b24efc3b030 in "libdtrace.so.2" > "strlen" in "libdtrace.so.2" ==> 0x1b24edfdfc30 in "libc.so.7" > "yybegin" in "libdtrace.so.2" ==> 0x1b24efc39b00 in "libdtrace.so.2" > "setjmp" in "libdtrace.so.2" ==> 0x1b24edf3ede0 in "libc.so.7" > "yyparse" in "libdtrace.so.2" ==> 0x1b1cc46fe300 in "mdb" > > The last line is what causes the trouble. > It's interesting that yyinit and yybegin were resolved correctly... ah, but > there are no such symbols in the main binary. > > Additional info: > > $ nm -D /usr/local/bin/mdb | grep yyparse > 00000000000b6300 T yyparse > > $ nm -D /usr/local/lib/mdb/kvm/amd64/dtrace.so| grep yyparse > $ > > $ nm -D /lib/libdtrace.so.2 | grep yyparse > 0000000000066460 T yyparse > > $ nm -D /usr/local/bin/mdb | grep yybegin > $ > > -- Andriy Gapon