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 6888B3850433 for ; Tue, 19 Jan 2021 15:00:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6888B3850433 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-167-PNaCdMrsP1OrckGuK3w3DQ-1; Tue, 19 Jan 2021 10:00:02 -0500 X-MC-Unique: PNaCdMrsP1OrckGuK3w3DQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B3EC8800D55; Tue, 19 Jan 2021 15:00:00 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-110.ams2.redhat.com [10.36.112.110]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8EE4760C9C; Tue, 19 Jan 2021 14:59:59 +0000 (UTC) From: Florian Weimer To: Fangrui Song Cc: binutils@sourceware.org, libc-alpha@sourceware.org Subject: Re: ifunc resolving References: <20210118220403.nzq6imfmaluuavfp@gmail.com> Date: Tue, 19 Jan 2021 15:59:54 +0100 In-Reply-To: <20210118220403.nzq6imfmaluuavfp@gmail.com> (Fangrui Song's message of "Mon, 18 Jan 2021 14:04:03 -0800") Message-ID: <87sg6xezv9.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.6 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_H3, 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-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 15:00:10 -0000 * Fangrui Song: > I have seen ifunc relocation activities on glibc and ld recently. > https://sourceware.org/glibc/wiki/GNU_IFUNC is under-documented, some aspects > have not been well-known, and there are a lot differences across architectures > supporting ifunc, so I am sending this email hoping that these aspects can be > clarified, toolchain developers can get on the same page, and documentation can > be improved (if developers get confused at times, how could regular users > comfortably use them? :) ) We have two positions that still need to be reconciled: * IFUNC resolvers must not themselves have relocation dependencies because they can be called at any time during relocation. This restricts the functionality available to an IFUNC resolver. * IFUNC resolvers may have relocation dependencies, but they may only be called after the object that contains them has been relocated. This restricts how IFUNC symbols can be used (interposition is limited, correct dependency ordering via DT_NEEDED is required). I do not think we have ever achieved consensus which position is the correct one. We have removed several IFUNC resolvers with IFUNC dependencies from glibc itself because we could not follow the interposition/dependency rules for the second approach. Due to the x86-specific checks we have, those architectures currently land in the second category. I do not know if other architecture maintainers agree. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill