From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1DD0C1F4B4 for ; Tue, 19 Jan 2021 16:47:54 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0490B3857C77; Tue, 19 Jan 2021 16:47:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0490B3857C77 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611074873; bh=X0gsvkH7ZGeY2k9eX5RJa0tXDjKqQjWSJIsYCxQ/xfg=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=JjfGM0/SIkWLUPytznZ14tRgl6+L868/g6qqeNGmWD/u9bMlxMAZ0d8rPx6wyGUGz j40RFjaaKJWTE95z1mXU3oeVWXPyZ50Q/ZhEVVToYsk/Lx2FzvRGDHdW/83E/62cyx U63maoLWJICq/mljLc0+xZLvF+1AjDXtmdue3/rw= Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 3A34C3857C5F for ; Tue, 19 Jan 2021 16:47:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3A34C3857C5F Received: by mail-oi1-x22f.google.com with SMTP id w8so27602oie.2 for ; Tue, 19 Jan 2021 08:47:49 -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=X0gsvkH7ZGeY2k9eX5RJa0tXDjKqQjWSJIsYCxQ/xfg=; b=nLkWpoMazMItTgY+qh6M9LcXfU+2Inic1MyyxTy+UHi4PbFa85IhX64LRwmivbXrSr 0kw5Tggrd0b6R2S5j+0XfvFfrhKx3Cnapzv0X1mqQFyy+HdqFtK/Zfg4iIbRGk69Aaev 18xRODK70hfvOC9y4SXEc5hB5hKNpREgPr5PyG5wzY0CdxE79ei5dpMR8mp9ZyDMn/nh 8MySy4Bo/hNonT631ybIDycsDRASJj4tJ9M3FlFS8b0CLFBqm3B9GvKGWFwT8s1gxcHV J+XID88zp7bIgd7CVhnner+7BoAdDoP6U8iZ93nkMY84OyEGIyJcGABiWZV6L33UoZNa ydeA== X-Gm-Message-State: AOAM532k4V7dT7OnJOCihPBj54H2z2y2doKT/NVPtYFneIsnDGdF5ukw Zw8ARc/YKIyKHfyRwmoz4QR+Hh35goRwPITAgimCkNkQECk= X-Google-Smtp-Source: ABdhPJwcoyXqV4WsfbCBSe2PjwH22WyFKqp6gHPFqhUTRnieLrX0cta2t/I2Mdez8sZuk5TLefiVY7e0QCyR9ciF1K8= X-Received: by 2002:aca:4d8b:: with SMTP id a133mr356744oib.79.1611074868619; Tue, 19 Jan 2021 08:47:48 -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: Date: Tue, 19 Jan 2021 08:47:12 -0800 Message-ID: Subject: Re: [PATCH v4 08/10] csu: Move static pie self relocation later [BZ #27072] To: Szabolcs Nagy Content-Type: text/plain; charset="UTF-8" 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: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Tue, Jan 19, 2021 at 7:32 AM H.J. Lu wrote: > > 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? Does arm64 linker always define __ehdr_start? If yes, can you drop "weak," to see if RELATIVE goes away? > > > > > > 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. -- H.J.