From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 67CCF3814FF5 for ; Tue, 24 May 2022 17:28:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 67CCF3814FF5 Received: by mail-pl1-x62c.google.com with SMTP id i1so16426022plg.7 for ; Tue, 24 May 2022 10:28:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=fAX9ZrsCU8aG9jxJCpJKH+6qdtIa6Nrh4lvroHI6VIY=; b=FwinalbTiYGmEVHdsccGXWvdpMSShhDTiUMiXs4+/IDik2xHIyJ0vxPOmcGs5jqyie mp1sJe3T5b4pRfMwILZfLMrxE0Ll0VFHtZGmClUw0Wn4zICOXRg20LHpCMtSXLD8v4pr PHdcOOzGblRddLJfuuiehcO4fdTnV5IRz8a3zv0XtWtmb/w/dAkDAAE+FDHrVAKvRHgP bAcKd9NDFZWDWJQL1fT4FIkgQRUU1P8sT4skP6LdFzPhmo6ZOdjrR0zJaB9so9O9iLz5 cuj5fwCMkfJCMAB7iqetI71391CSNbPMEzWus0uqQfutnCfftsFYu+EMeHn2QmCLWKaa d4mQ== X-Gm-Message-State: AOAM530LJnUHwc56QnWA0qVgysJPIURsEvE1IHPN5oiJZ/aWxk9/XfYe B6zC2+RwaBSv/3Cb11FPKepvTiExEpJSIQ== X-Google-Smtp-Source: ABdhPJwjb5H+Mz+OebTszCrEkyeNtpOeZU5Ms2/GIhWtBMk23pGFzDiB/WujrkzT+NKaEisTfELWBA== X-Received: by 2002:a17:90a:5d04:b0:1e0:83d7:413c with SMTP id s4-20020a17090a5d0400b001e083d7413cmr3180980pji.201.1653413312249; Tue, 24 May 2022 10:28:32 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:a875:ceeb:f6fb:e7e2]) by smtp.gmail.com with ESMTPSA id k11-20020a170902760b00b0015eaa9aee50sm7441209pll.202.2022.05.24.10.28.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 10:28:31 -0700 (PDT) Date: Tue, 24 May 2022 10:28:28 -0700 From: "maskray@google.com" To: Wilco Dijkstra Cc: Szabolcs Nagy , 'GNU C Library' Subject: Re: [PATCH 2/3] Revert "[AArch64][BZ #17711] Fix extern protected data handling" Message-ID: <20220524172828.7gawda2en7nx6zg3@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-19.4 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 24 May 2022 17:28:35 -0000 On 2022-05-24, Wilco Dijkstra wrote: >Hi, Hi Wilco, >>> * Clang code generation treats STV_PROTECTED the same way as STV_HIDDEN: >>> no GOT-generating relocation in the first place. > >We should change GCC's behaviour to match this - is this something that >applies to all targets? I have a blog post on the topic about copy relocations and protected symbols: https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected "The GCC pessimization applies to all ports with #define TARGET_BINDS_LOCAL_P default_binds_local_p_2." The aarch64 pessimization was due to the side affect of a commit attempting to fix another issue: commit cbddf64c0243816b45e6680754a251c603245dbc (From-SVN: r222992) >>> * gold and lld reject copy relocation on a STV_PROTECTED symbol. >>> * Nowadays -fpie/-fpic modes are popular. GCC/Clang's codegen uses >>> GOT-generating relocation when accessing an default visibility >>> external symbol which avoids copy relocation. > >Would it be reasonable to add a way to override settings for binaries? >For example if all imported symbols are marked with the correct visibility, >PIE binaries could avoid using GOT for default visibility external symbols to >get better performance. And non-PIE binaries could force GOT accesses for >non-default visibility to avoid copy relocations and support protected visibility. In Clang, -fno-direct-access-external-data is such an option:) --- Regarding function symbols, there is a bit which should be fixed: "Protected function symbols and canonical PLT entries"