From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60854 invoked by alias); 16 Oct 2019 12:55:18 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 60846 invoked by uid 89); 16 Oct 2019 12:55:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=Beyond X-HELO: mx1.redhat.com From: Florian Weimer To: Szabolcs Nagy Cc: Adhemerval Zanella , nd , "libc-alpha\@sourceware.org" Subject: Re: [Question] ifunc odering in ELF References: <1568314984.28076.65.camel@blackberry.com> <87pnjzy75u.fsf@oldenburg2.str.redhat.com> <66583af6-6049-7f1d-0a31-a77a228cf603@linaro.org> <87v9tnezju.fsf@oldenburg2.str.redhat.com> <0a862d00-8b76-4015-3750-f05636544611@arm.com> Date: Wed, 16 Oct 2019 12:55:00 -0000 In-Reply-To: <0a862d00-8b76-4015-3750-f05636544611@arm.com> (Szabolcs Nagy's message of "Fri, 20 Sep 2019 16:00:39 +0000") Message-ID: <87imoo4zpr.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-10/txt/msg00485.txt.bz2 * Szabolcs Nagy: > On 20/09/2019 16:51, Florian Weimer wrote: >> * Adhemerval Zanella: >>=20 >>> That's was not my impression, I this we should to go this way iff we ca= n't >>> really make IFUNC reordering work on loader. From your initial work on >>> the two-phase IFUNC relocation, which prevents us to move forward? >>=20 >> No one said, =E2=80=9Cyes, we do need this feature in the loader=E2=80= =9D. >>=20 >> (Keep in mind that it does not solve all ordering problems, the example >> in this thread would still break.) > > if most "reasonable" ordering issues can be fixed, then > i think the ordering should be fixed. > > but i seem to remember that for it to work it's not enough > to consider the relocations of a single module, Current binutils already orders IRELATIVE relocations after all other relocations. I haven't checked (or don't recall) if the sorting also treats likely self-bindings specially (ordering them after other relocations). Beyond that there is little we can do in the link editor because the problematic scenarios involve preloading, so there's just not a complete picture and link time. > but other modules have to be considered (in case of copy relocated > function pointers? or extern ifunc code in not yet relocated > modules?). The patch I posted is global in effect: > if relocations have to be processed twice across multiple > modules then i think the complexity is too much (we need to > allocate space for the list of relocs that need reprocessing > etc). Right, the patch does that. Looks like I read the consensus on the list correctly. 8-/ I guess I'll keep working on eliminating the remaining relocation dependencies (and others) in glibc's IFUNC resolvers. Thanks, Florian