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.1 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 2612E1F466 for ; Mon, 3 Feb 2020 22:03:49 +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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=LdBkQ/PA8Y0DPG04 ZNiuDhQJkLZyfRWriGq09AEBZ1VipxwNxsTPGJoPydXwVxny2ClmutOkPcV2ThFe IleYUrZpkXq7P3AGko9KpVXxyi485pDPgB0uqMnJFXboGaUnuUhjQE3g7vM0Kxu9 ZJVhLMxMVEr601trzFUxftBHucA= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=AHCNgTN2s4PqlclJHDOKI2 AZ7v8=; b=L0tnQzO92g1q81UYeFIGhtsuBDzugXkNRTC8ZhEjXjLpIn59BbFI+S KTe8qSXmqrZle1/kRx0wj93ZMylkfvBLGLcdES+jEyeW/6doWGwUSuYBd2ELlV4p LiTdz8lbuyN+pqu1EAjVYKDqeseFaoiAl52wbMs5EramLhl/NMPWc= Received: (qmail 63973 invoked by alias); 3 Feb 2020 22:03:46 -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 63960 invoked by uid 89); 3 Feb 2020 22:03:46 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580767422; 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=A5LjzqXxCF2hXmSZX0i73i/Dn5TFCZs6LVMr2XRfMtw=; b=HTWQTh0A5OajTDY+MLrvsdoyc3g3u54qo+LZG5RoOHIqKev1pmMkl8ZAeiBSMbtHZy+T7W ns2OqIJyJ08scRjAoyxeMKUWdrcsDb1uRo1AokA8B0fX3hJ7uXCexzTEhH6lmbkrnwSyLX IJwN9IGbDP4Sl49kKeOMYjPtoPtuUlg= Subject: Re: Are ifuncs intended to be allowed to resolve to symbols in another DSO? To: Florian Weimer Cc: Zack Weinberg , GNU C Library References: <87sgko4b91.fsf@oldenburg2.str.redhat.com> <559bbced-2f06-4196-719a-923e6c804e1d@redhat.com> <87tv47jv05.fsf@oldenburg2.str.redhat.com> From: Carlos O'Donell Message-ID: <7012c618-01f4-1e4d-51d0-6491a5e61e2f@redhat.com> Date: Mon, 3 Feb 2020 17:03:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <87tv47jv05.fsf@oldenburg2.str.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 2/3/20 3:06 PM, Florian Weimer wrote: > * 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. Just so I understand the position is, to simplify the implementation, that IFUNC resolvers must not use any non-local relocations? What does non-local relocations mean? Are we saying the target of all relocations must be within the same linkmap as the resolver? Are we saying then that resolvers can only manipulate local data and make local function calls? I don't think that would be useful since you'd want to call many libc functions from the resolver itself and so you would have calls in the resolver that could call through a GOT entry that has a relocation against an external symbol in another DSO e.g. libc.so.6. If an IFUNC resolver has relocations that against non-local symbols then those symbols must have been a dependency of the object and listed in DT_NEEDED and therefore relocated before the current IFUNC resolver is running. > 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. I don't quite parse your first setnence here, could you expand on that please? When you speak about luxury, you mean to say that IFUNCs in other projects would not have the same possibility to solve such a problem like we do in glibc? >> 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. What exact problem does symbol interposition cause? >> I like solutions that ensure that IFUNC resolvers, which are just foreign >> functions, run at a stage *after* their own dependencies have been resolved, >> 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. The dependencies are explicitly tracked by DT_NEEDED. Then when we have underlinked libraries we try to suppliment this and reorder by relocation dependencies. This may be causing more problems than it solves? If we had good visibility into the load order manipulations because of the relocations I think users would understand the consequences of these problems and we would also be able to better identify underlinked applications and file bugs to fix them (if possible). -- Cheers, Carlos.