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 9E1B01F55A for ; Fri, 21 Feb 2020 13:28:58 +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=PQikxRfLP5JZhQ9VQ09TI4pQ0kzf2FVoK6R9K3dwGyy 2koPSHA6qTKWZObw0OlEnuJkH+vLGVvEmGELAfcU8ip396p8VVy/QTDL3VyMaPuM 64iepj/py1rGeiTGsnxlCrKgioHdmnATpw0HvKqvd6CG2ApqyqLFqrjYb+XRx8jc = 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=4R9kUXq2RkVnz0jCwXbG9Orgntk=; b=J5pUlt21TCZlrRpvH kNyQMcYOQRq2Jim5BvX2tUkqORgVOTXC5E/jxWZI7N0y8KXmVZi0fhaD4I8G0iLG /uDL3e+2at029nFhEpTiHtyD9tSxrdXr8Hc+XSiHT5nnTs4Ipftk2UGZmmd/KdO/ tt62dBnpphpoaZC2ds26bDOnoM= Received: (qmail 89388 invoked by alias); 21 Feb 2020 13:28:56 -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 89375 invoked by uid 89); 21 Feb 2020 13:28:55 -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=1582291732; 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=hBWi2QXrxUIjQBTWJZubxFVITQosusmiNW4xxhDFygM=; b=gG0a1ZiC07fVLx2gXkr30k4ZXpg/nVmnhIhbj8CaAqSr5bOVqxfUJuluXzrsJJ5KpmsQyb sxNBwBdxIQnA0xEkdTvpWP3/G7KPPIhEKnNig7MX+r2olOjrmczJKDQAkbyfUC4QTivO7S 1DC4BKj6uO9YpoigP5DsgrVH1E5qjb4= 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> <87tv47jv05.fsf@oldenburg2.str.redhat.com> <7012c618-01f4-1e4d-51d0-6491a5e61e2f@redhat.com> Date: Fri, 21 Feb 2020 14:28:44 +0100 In-Reply-To: <7012c618-01f4-1e4d-51d0-6491a5e61e2f@redhat.com> (Carlos O'Donell's message of "Mon, 3 Feb 2020 17:03:37 -0500") Message-ID: <871rqogjcj.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: > On 2/3/20 3:06 PM, Florian Weimer wrote: >> * Carlos O'Donell: >>=20 >>> If an IFUNC resolver calls a function which is not yet resolved then >>> isn't that a defect in the IFUNC resolver? >>=20 >> 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, tha= t > IFUNC resolvers must not use any non-local relocations? It means no location depedencies at all for PI_STATIC_AND_HIDDEN targets. I think this is actually the current consensus, as expressed in the implementation. I don't know how to express this requirement for !PI_STATIC_AND_HIDDEN targets. Fangrui Song explained potential problems there. We probably should not add IFUNC supports for targets that are not PI_STATIC_AND_HIDDEN. If every function call and data reference goes through a GOT-like construct, that can never work with IFUNCs with symbol references that do not strictly follow the order of dependencies and thus relocation processing in the dynamic loader. > 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. ELF constructors are another concern here. Relocation processing happens before they run, so such calls will see uninitialized libraries. We can make this work for libc.so.6, but currently, it's not very reliable, especially for things that user may actually want to use, like getenv. >> 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? The toolchain currently does not permit IFUNC resolvers which depend on most run-time relocations for work. libpthread violated that requirement for vfork (and earlier for other functions). >>> The code which contains such an IFUNC should have had a DT_NEEDED entry >>> on all objects to which the resolver called into? >>=20 >> This does not help with symbol interposition. > > What exact problem does symbol interposition cause? It introduces symbol dependencies which are not reflected in the DT_NEEDED dependencies. This means that the relocation order chosen by the dynamic loader does not meet the actual requirements of IFUNC resolvers. >>> I like solutions that ensure that IFUNC resolvers, which are just forei= gn >>> functions, run at a stage *after* their own dependencies have been reso= lved, >>> but before their own initializers have run. >>=20 >> 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. Not for symbol interposition. Thanks, Florian