From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 6B645393BC3C for ; Tue, 19 Jan 2021 15:33:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6B645393BC3C Received: by mail-ot1-x333.google.com with SMTP id v21so2373016otj.3 for ; Tue, 19 Jan 2021 07:33:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q+48LuWYlq4Kt3XL96eXW8bGMqeJK5I0CYQlF2u5rEg=; b=qOM3NW3PTl2BzGyppFn/HOvoahOp7jsPFvkmtL35EH5CqHyfmq0xAbd8p1CyN46N7s uwuZpXaKjQNSrIRuYYuq0t+Sg2o7K26EtKkyBbFYKUB0UcPINcVRfR49sxiiJbSMhZrL 0CmNaMfheIRiT0A0/ob02qbr9fFYQZj2+Q+3jO4/njDgsYnLnr/3HOeOKrA58/rvF0yC ezbKlEpj9GbcAGy3t7c1R/uJHx1YKLVCtA924D1fP1WI1z90mBBZSLHJ+EtSwToEI9Cn d7Xa1MOCIDuyHqWCMMieAtu2rd1u0oJT9kyYDdDonm6l5nKfcAMmV9C8uQRN/zTyFSlh EnEw== X-Gm-Message-State: AOAM532SQnEOuQ5elBnQThlJsJR2BicEap00LVp5/oQ32kVzm8cIX7Nq +v1wlH12z7yg6Sf8YSIHsSUM1Yxhlqrf6RR6qWg= X-Google-Smtp-Source: ABdhPJxtt1aquAFSFRYQ+1NGmRy/wX5pG4faVOb3YiaVKen4HYzU3avbd0PGVQSwJetDEhrveXPpqTX33SIhSS1tsOY= X-Received: by 2002:a9d:6285:: with SMTP id x5mr3819454otk.179.1611070405871; Tue, 19 Jan 2021 07:33:25 -0800 (PST) MIME-Version: 1.0 References: <4224b7c0428492696fe6d6c01739adcf69fc677d.1610986541.git.szabolcs.nagy@arm.com> <1ba70d1b-08f8-6a5d-ecf4-45200744c9d8@linaro.org> <20210119143500.GA3445@arm.com> <20210119152441.GB3445@arm.com> In-Reply-To: <20210119152441.GB3445@arm.com> From: "H.J. Lu" Date: Tue, 19 Jan 2021 07:32:49 -0800 Message-ID: Subject: Re: [PATCH v4 08/10] csu: Move static pie self relocation later [BZ #27072] To: Szabolcs Nagy Cc: Adhemerval Zanella , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3030.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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:33:27 -0000 On Tue, Jan 19, 2021 at 7:24 AM Szabolcs Nagy wrote: > > The 01/19/2021 06:48, H.J. Lu wrote: > > On Tue, Jan 19, 2021 at 6:37 AM Adhemerval Zanella via Libc-alpha > > wrote: > > > > > > > > > > > > On 19/01/2021 11:35, Szabolcs Nagy wrote: > > > > The 01/19/2021 11:07, Adhemerval Zanella wrote: > > > >> On 18/01/2021 13:25, Szabolcs Nagy via Libc-alpha wrote: > > > >>> IFUNC resolvers may depend on tunables and cpu feature setup so > > > >>> move static pie self relocation after those. > > > >>> > > > >>> It is hard to guarantee that the ealy startup code does not rely > > > >>> on relocations so this is a bit fragile. It would be more robust > > > >>> to handle RELATIVE relocs early and only IRELATIVE relocs later, > > > >>> but the current relocation processing code cannot do that. > > > >>> > > > >>> The early startup code before relocation processing includes > > > >>> > > > >>> _dl_aux_init (auxvec); > > > >>> __libc_init_secure (); > > > >>> __tunables_init (__environ); > > > >>> ARCH_INIT_CPU_FEATURES (); > > > >>> > > > >>> These are simple enough that RELATIVE relocs can be avoided. > > > >>> > > > >>> __ehdr_start may require RELATIVE relocation so it was moved > > > >>> later, fortunately ehdr and phdr are not used in the early code. > > > >>> > > > >>> Fixes bug 27072. > > > >> > > > >> LGTM, thanks. > > > >> > > > >> Reviewed-by: Adhemerval Zanella > > > > > > > > > > > > sigh, this is an old version of this patch, i made a > > > > mistake putting the series together. > > > > > > > > the problem is that _dl_phdr is used in ARCH_SETUP_TLS > > > > (to get the tls program headers) so the __ehdr_start > > > > magic should be before that (this only matters if auxv > > > > lacks AT_PHDR for some reason, which should not happen > > > > normally on linux, so testing won't show the problem) > > > > > > By normally do you mean it might happen on a specific kernel version > > > or is it architecture specific? > > i guess __ehdr_start symbol can be useful and with it > glibc does not have to depend on auxv (which an elf > loader like valgrind/qemu-user may get wrong) > > however it is only used as a fallback and on linux > AT_PHDR is always expected to be present. (i don't > know if this ever triggers) Only used on Hurd? > > > > I think we can leave __ehdr_start ASIS since it doesn't need RELATIVE > > relocation. I verified it by adding -Wl,-z,report-relative-reloc when building > > elf/sln on x86. > > it needs relative reloc on aarch64: it can be an undefined weak > symbol and that must be 0. a pc relative address computation > cannot give 0 (unless linker does some instruction rewriting, > but on aarch64 the address computation is multiple instructions > that can be spread far apart). so yeah it needs a GOT entry and > that will be either 0 or needs a RELATIVE reloc. On x86, I converted load from GOT to simple LEA without RELATIVE in this case. But this is an x86 specific optimization. -- H.J.