From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by sourceware.org (Postfix) with ESMTPS id 6B3BA3857C52; Wed, 20 Jan 2021 16:13:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6B3BA3857C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=panix.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zackw@panix.com Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4DLVtc5lTsz1q4s; Wed, 20 Jan 2021 11:13:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1611159192; bh=3lid1GhVJSd+PvR1HEXRNx2ItKFWzTLpXbLNKZZJh0k=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=d/7p9y5MpEDFHuYB3x76YKKxbS5q+aq6+IetQkmvGr2iRrP+cYq+xI937sjM/6eQE 9DiC9ON+ZCMcsrZuVqbwa5DAp/7vAqcDmTjZiCHx9gy2lPaLnKCT1AF3IIhTCZFkhw pcTdIxrP9QtadezWP/APP9DfUUxWCGlFs7mSi8+8= Received: by mail-ed1-f48.google.com with SMTP id n6so11323224edt.10; Wed, 20 Jan 2021 08:13:12 -0800 (PST) X-Gm-Message-State: AOAM530P1aa6ZIH9uBmbcr26l5tRmLM9Yi4i/tkfkIC7eyO3/6x1I2bH gDpvFDRey0BpI40di2SzT3995fb7cWBiitgJjX0= X-Google-Smtp-Source: ABdhPJyVRmQ3pQGJuhxxE5grWhv0Nq3HJ6ubWqOzApk8nwsHKCcq2ws0M+y1Nop+WnaTzajP6jYrzSw/DOEePMVrvX4= X-Received: by 2002:a05:6402:5206:: with SMTP id s6mr7717657edd.92.1611159191679; Wed, 20 Jan 2021 08:13:11 -0800 (PST) MIME-Version: 1.0 References: <20210118220403.nzq6imfmaluuavfp@gmail.com> <87sg6xezv9.fsf@oldenburg.str.redhat.com> <20210119223153.GZ26219@bubble.grove.modra.org> <87lfco6jgr.fsf@oldenburg.str.redhat.com> In-Reply-To: <87lfco6jgr.fsf@oldenburg.str.redhat.com> From: Zack Weinberg Date: Wed, 20 Jan 2021 11:13:00 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ifunc resolving To: Florian Weimer Cc: Alan Modra via Libc-alpha , Fangrui Song , binutils@sourceware.org, Alan Modra Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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:13:14 -0000 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... zw