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.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, 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 F39941F4B4 for ; Tue, 19 Jan 2021 17:39:16 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 25C893938C00; Tue, 19 Jan 2021 17:39:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 25C893938C00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611077956; bh=BKYkqXyvYA3mIQDIVtSTRhxzlHVwgtaYcoE4ZfcgrP0=; 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=D2W+8SEUOTBkF0l8oh+VoUxYsJJN5sh5yUmufTA37ug6AS1H+wPwa0JXbMJTFnC1/ 7VLmCVX10+eAlLKAFYltHlVppVwT5Ermg9+iVPVWTB7MFOAqGpGbWJr7K94txckeL9 mb1+xiK++94KKfKJ/mR1Sj54xd6l2fuD1NZnL/C4= Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 9BD063870891 for ; Tue, 19 Jan 2021 17:39:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9BD063870891 Received: by mail-pf1-x429.google.com with SMTP id q20so12684165pfu.8 for ; Tue, 19 Jan 2021 09:39:08 -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:content-transfer-encoding; bh=BKYkqXyvYA3mIQDIVtSTRhxzlHVwgtaYcoE4ZfcgrP0=; b=UWSTptPcw3cuNlI4xmgdEUzEciR2cyUQ8v5B2fb97eXHf1ITI4hS2dNTgm5DxIB9bl OsLmYFtLc7dsrPiL93UXURqKqWJhAAeNE3cV2yl3xphtJQ+1RSU27chnbZK05AZI9Vjx kn0CZui7RZ9rGmyvCUcD3PX3WIcsLGbsRMy/8Os3gSS317585yLH6lBipUMkmTUfiioH 3k9nskzpVJyADCuE/WCGv6zHiDbT8tEQBSNKQHu85gzV55WIdGzkRlqFez0k0bM9dmZK LRc/10ulisMzNAAoGESV2S9egRmm8+1TYiGhbyFbbNjck+zZabph75bHKP1LtJN52XHx g40g== X-Gm-Message-State: AOAM530EJrGZDu4eSyH1QFT8z5dF4LS5J1Ote87dTbg6RbK05ZDK+vGb a0uxuQwROZZHn2OXWP9cktm69/o6oQSQfXW/+FAsYQ== X-Google-Smtp-Source: ABdhPJyyMzkGiLsFLXcmayKIkEIMmR84USnNX+dTls3bGS/8KA0YbEBkAzxIMoPOn+VSuJHFbmszxt+atVO66KdZVSA= X-Received: by 2002:a65:628a:: with SMTP id f10mr5341789pgv.380.1611077947587; Tue, 19 Jan 2021 09:39:07 -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> <20210119170319.GC3445@arm.com> In-Reply-To: Date: Tue, 19 Jan 2021 09:38:56 -0800 Message-ID: Subject: Re: [PATCH v4 08/10] csu: Move static pie self relocation later [BZ #27072] To: "H.J. Lu" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: =?utf-8?q?F=C4=81ng-ru=C3=AC_S=C3=B2ng_via_Libc-alpha?= Reply-To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Tue, Jan 19, 2021 at 9:34 AM H.J. Lu wrote: > > On Tue, Jan 19, 2021 at 9:26 AM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > > On Tue, Jan 19, 2021 at 9:11 AM H.J. Lu wrote: > > > > > > On Tue, Jan 19, 2021 at 9:03 AM Szabolcs Nagy = wrote: > > > > > > > > The 01/19/2021 08:47, H.J. Lu wrote: > > > > > On Tue, Jan 19, 2021 at 7:32 AM H.J. Lu wro= te: > > > > > > 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 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 ker= nel 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 dr= op > > > > > "weak," to see if RELATIVE goes away? > > > > > > > > __ehdr_start support was added in binutils 2.23 > > > > > > We may assume binutils >=3D 2.33 when building for static PIE > > > since all static PIE linkers should define __ehdr_start. > > > > > > Does lld define __ehdr_start? > > > > LLD defines __ehdr_start as hidden if it is not a defined symbol in > > -no-pie/-pie/-shared modes. > > The behavior seems to match gold. GNU ld seems to use STB_LOCAL > > STV_DEFAULT but the exterior behavior should be the same. > > I am not sure where you got such incorrect info. Both ld and gold were c= hanged > to STV_HIDDEN in 2013 by the same commit: > > ommit cde7cb0129a884a060b99c7c83e8f5c9af728b0a > Author: Maciej W. Rozycki > Date: Fri May 3 15:19:27 2013 +0000 > > gold/ > PR ld/15365 > * layout.cc (Layout::finalize): Make __ehdr_start STV_HIDDEN. > > ld/ > PR ld/15365 > * emultempl/elf32.em (gld${EMULATION_NAME}_before_allocation)= : > Restrict __ehdr_start's export class to no less than STV_HIDD= EN. > > -- > H.J. % cat a.s .global _start, __ehdr_start _start: leaq __ehdr_start(%rip), %rax % gcc -fuse-ld=3Dbfd -nostdlib a.s -o a.so % readelf -Ws a.so ... 9: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 __ehdr_start When the binding is STB_LOCAL, the visibility does not really matter. ELF spec: "A symbol with STB_LOCAL binding may not have STV_PROTECTED visibility. A hidden symbol contained in a relocatable object must be either removed or converted to STB_LOCAL binding by the link-editor when the relocatable object is included in an executable file or shared object."