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 E44613857C52 for ; Wed, 20 Jan 2021 16:17:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E44613857C52 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-531-Z-CuQF0XOsqzya0H4uegqw-1; Wed, 20 Jan 2021 11:17:36 -0500 X-MC-Unique: Z-CuQF0XOsqzya0H4uegqw-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 CB881192D785; Wed, 20 Jan 2021 16:17:34 +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 2995460D06; Wed, 20 Jan 2021 16:17:32 +0000 (UTC) From: Florian Weimer To: Zack Weinberg Cc: Alan Modra via Libc-alpha , Fangrui Song , binutils@sourceware.org, Alan Modra Subject: Re: ifunc resolving References: <20210118220403.nzq6imfmaluuavfp@gmail.com> <87sg6xezv9.fsf@oldenburg.str.redhat.com> <20210119223153.GZ26219@bubble.grove.modra.org> <87lfco6jgr.fsf@oldenburg.str.redhat.com> Date: Wed, 20 Jan 2021 17:17:26 +0100 In-Reply-To: (Zack Weinberg's message of "Wed, 20 Jan 2021 11:13:00 -0500") Message-ID: <874kjb4m7d.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.5 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: Wed, 20 Jan 2021 16:17:40 -0000 * Zack Weinberg: > On Wed, Jan 20, 2021 at 4:33 AM Florian Weimer via Libc-alpha > wrote: >> * Alan Modra via Libc-alpha: >> > On Tue, Jan 19, 2021 at 03:59:54PM +0100, Florian Weimer via Binutils wrote: >> > There is a third possibility. If ld.so defers all irelative and other >> > relocations using ifunc symbols until all non-ifunc relocations have >> > been performed, globally, then ifunc resolvers would only have the >> > restriction that they not call other ifuncs. >> > >> > That idea was floated a very long time ago. For some reason it is >> > too hard or too slow to do in ld.so. >> >> It's not too hard, I wrote a patch. I didn't mention it because it was >> rejected. It seemed about the only thing for which we had consensus. 8-/ >> >> My patch did not find an appropriate order in all cases. I think that's >> more or less unavoidable if IFUNC resolvers depend on relocations >> against other IFUNC resolvers. It would have nicely covered all >> internal glibc uses at the time. > > Every time this discussion comes up, I wonder how much it would help > if we completely scrapped the idea of lazy relocations. Do what > LD_BIND_NOW=t does all the time. Distributions are moving in this > direction already because that lets them turn on -z relro... Lazy relocations make this much easier (if they can in fact be used). Some tcmalloc versions called getenv from an IFUNC resolver and it actually worked. BIND_NOW broke it. 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