From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id CA6E33857808 for ; Sun, 27 Jun 2021 14:44:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA6E33857808 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-275-vsUjAT0CM-aDYcXWfOIpwQ-1; Sun, 27 Jun 2021 10:44:29 -0400 X-MC-Unique: vsUjAT0CM-aDYcXWfOIpwQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A29A6100B3AC; Sun, 27 Jun 2021 14:44:28 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-228.ams2.redhat.com [10.36.112.228]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E305B60C0F; Sun, 27 Jun 2021 14:44:27 +0000 (UTC) From: Florian Weimer To: Fengkai Sun via Libc-help Cc: Fengkai Sun Subject: Re: Why does dynamic linker search global scope before local scope? References: Date: Sun, 27 Jun 2021 16:44:26 +0200 In-Reply-To: (Fengkai Sun via Libc-help's message of "Sun, 27 Jun 2021 22:29:40 +0800") Message-ID: <87lf6v4bat.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 14:44:33 -0000 * Fengkai Sun via Libc-help: > After reading some LD_DEBUG messages, I've found that the dynamic linker > searches the global scope before the local scope, and the flag > RTLD_DEEPBIND can change this behavior. > > I'm really curious about the reason why the dynamic linker won't search the > local scope first by default. To me, the static linker finds out the > dependencies of a DSO, and there is a very high probability that they are > defined in one of the DT_NEEDED entries. One can use the symbols in the > global scope to do interposition, but that is quite rare, so always > searching in the global scope seems tedious. Interposing symbols from the main program is fairly common. malloc is the most obvious example, but this also happens with certain plugin frameworks where the framework is available as both an executable (with the framework statically linked) and a shared object. In the latter case, some shared objects may link against the framework dynamically, but if running under the executable, the definitions in the executable must be used. Such an approach used to be quite common before the effects of cheap PC-relative addressing, LTO and lack of semantic interposition of locally-defined symbols were more widely understood. > Currently, LD_PRELOAD is in the global scope, after the main executable. > Though the use of RTLD_DEEPBIND may invalidate the preload semantics, it's > just a design choice. The dynamic linker can search local scope first, and > add LD_PRELOAD somewhere in the local scope. Interposition does not necessarily involve LD_PRELOAD. Thanks, Florian