From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 785D41F880 for ; Thu, 9 Jan 2020 20:37:43 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=eHQvKQcztPQmNTDMat4k26zvk2joHwQS5EiuDpg7K7J v+e9ntkHWo3QViHpxZ3um23fUFD9pnRLWwOroMHN3UI/ganSnM6k5uo9cCg+rZFi OvXnNc1SakFQPDEFkbSUyZv3vM4vGSqJzNqzBhj/6w7inHWt5Z+HmfMlj9K9SjnA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=+zQF4KPWNNzRY4/9vcWvwn0HAaU=; b=mCWPefx5PN8YJG514 6JnIq0xsfx5R+/HrdPjfel2L9o7bHChM4KHcw65DHtgsZnOLxrZCgm0LMc+LHzK2 dKvAKZCsBo7HbOlTkee6DW1pPMW99fzvzW9vGS2ZBZVEfqeeGSnWbzN8CV5eclzr D6Gkc5W/YtUf2BW5WkIdprXkuI= Received: (qmail 30231 invoked by alias); 9 Jan 2020 20:37:40 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 30218 invoked by uid 89); 9 Jan 2020 20:37:39 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-delivery-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578602257; 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; bh=81Hu0mzw+eNQYpxmOCSUk6ek2zm9kFIU5ekXaYvBOYI=; b=iYM5DbhTAZY0+M3PJ2cNu/3e9yj1DOchIot7Z1q+NLECRw1V4ObO1xDaB7WfK8+SbukXVN 9PB8htcIxf3ty8s+8NJZPro0XWQQK72FYECkVyPSMnWK02UOrQGtJmwJF2dKgz4qbPhhpw zCVtiCE7OQbc179ueXm1hnsdWDkB65w= From: Florian Weimer To: Zack Weinberg Cc: GNU C Library Subject: Re: Are ifuncs intended to be allowed to resolve to symbols in another DSO? References: Date: Thu, 09 Jan 2020 21:37:30 +0100 In-Reply-To: (Zack Weinberg's message of "Thu, 9 Jan 2020 13:29:08 -0500") Message-ID: <87sgko4b91.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable * Zack Weinberg: > Suppose I have two major versions of the same shared library > (libfoo.so.1 and libfoo.so.2) and the only difference is that > libfoo.so.2 drops a whole bunch of compatibility aliases. For > instance, libfoo.so.1 defines two names, `blurf` and `xblurf`, for the > same function, but libfoo.so.2 defines only the `blurf` name. > > Any program that winds up loading both shared libraries (via > transitive dependencies) is going to have two copies of the actual > code for `blurf` in memory. I could eliminate this duplication by > having libfoo.so.1 be a thin wrapper around libfoo.so.2, providing > only a definition for `xblurf` that calls `blurf`. Good so far, but > now old applications are making two jumps through the PLT whenever > they call `xblurf`. It occurred to me to wonder whether I could > eliminate the extra indirection (on the second and subsequent calls) > by making xblurf an ifunc: > > extern int blurf(char *arg1, int arg2); // defined in libfoo.so.2 > static int (*resolve_xblurf(void))(char *, int) > { > return blurf; > } > int xblurf(char *, int) __attribute__((ifunc("resolve_xblurf"))); This only works if libfoo.so.1 has already been relocated when the IFUNC resolver is called. Old glibcs always relocated objects in the wrong order (bug 12892, fixed in glibc 2.15, probably not widely backported). Even with that fixed, missing DT_NEEDED entries and LD_PRELOAD can result in calls to yet-unrelocated IFUNC resolvers. I had a patch to mostly fix this, but it added quite a bit of complexity (delayed relocation processing), and there are still difficult-to-describe failure cases for complex dependency trees. The community wasn't enthusiastic about it. Lazy binding obscures some of these problems, to the degree that some programmers call getenv in IFUNC resolvers. Thanks, Florian