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 26AD91F466 for ; Mon, 3 Feb 2020 20:06:56 +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=TjRJ5pc99L49byS+5ZgO/rOytihe3SskrtRNwWmgU4i azBRnAoJRKI9+i0WF2M5dPGdk6uPJmjfuaCh1jXBFoZPXFR/iK/pe8YbcG+zF9KT LmaL2UigKWfticsftuOvn+c28+1aGkkQb9Ssfb+TPjoTco/vzbnKTuBo1p5QOcrw = 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=zm+hOQ3HY80DTY/uCuEjt9CYHaQ=; b=j149Y1UrSQ3/aiA/Q JQAinxgK+C7GpXAweQnpnIFX2eVm5iMRwJ+boZqCMS0BiIh46dGEfvMdG4uLJnYI 1Bs7Dyz+p4ITJSmNiftlnZ5nDT4nYK00aPqX+ynVQCkdH3ofW7gk8mmCOHJjSYU1 mo4xD1BBH378eJFutZq0SJCPKc= Received: (qmail 97168 invoked by alias); 3 Feb 2020 20:06:53 -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 97159 invoked by uid 89); 3 Feb 2020 20:06:53 -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=1580760410; 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=TC5xqucToAMTOcRSkcnUpj0MubRtNi18lwwViNG2kiM=; b=cVa4t/t2KEYAtjulCIFV4lZUazlHr9G9TAhS04u5wZK4T2hxJ9oXeN43xo80cuZi9/sQ7H YqVlEs06ZyDiRKesWtsf4YZL+mikC2rcXdSEg7PoGvl7VXkA7EmVcoFCrbOmzCgBtw1gS7 CD4A/jj2lWB3WcO/GC8fjM19QOb87eQ= From: Florian Weimer To: Carlos O'Donell Cc: Zack Weinberg , GNU C Library Subject: Re: Are ifuncs intended to be allowed to resolve to symbols in another DSO? References: <87sgko4b91.fsf@oldenburg2.str.redhat.com> <559bbced-2f06-4196-719a-923e6c804e1d@redhat.com> Date: Mon, 03 Feb 2020 20:06:34 +0000 In-Reply-To: <559bbced-2f06-4196-719a-923e6c804e1d@redhat.com> (Carlos O'Donell's message of "Sat, 1 Feb 2020 01:27:23 -0500") Message-ID: <87tv47jv05.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 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable * Carlos O'Donell: > If an IFUNC resolver calls a function which is not yet resolved then > isn't that a defect in the IFUNC resolver? There is a position that an IFUNC resolver must not use any non-local relocations. (We must support some relocations for IFUNCs on !PI_STATIC_AND_HIDDEN targets.) In this case, yes, such a dependencies would be a bug because all external dependencies are bugs. On the other hand, in glibc, we could get rid of many IFUNC resolvers which violate this rule only after changing the loader that eliminated their need for them. Other IFUNCs that do not follow this rule do not have this luxury. > The code which contains such an IFUNC should have had a DT_NEEDED entry > on all objects to which the resolver called into? This does not help with symbol interposition. > I like solutions that ensure that IFUNC resolvers, which are just foreign > functions, run at a stage *after* their own dependencies have been resolv= ed, > but before their own initializers have run. Lazy binding achieves this because it implicitly tracks this dependency information. For eager binding, we simply do not have this information. Hence my patch for delayed relocation processing. But it does not solve the problem completely, of course. Thanks, Florian