From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 0A5063857371 for ; Tue, 24 May 2022 05:14:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A5063857371 Received: by mail-pl1-x62b.google.com with SMTP id m1so14919573plx.3 for ; Mon, 23 May 2022 22:14:04 -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=/hLJFxtCmeQYw7kTut2UW6spCSCNjYk10Xml4Z/aGhE=; b=p6Q8dFOiiR8Fch0ojL3FQOgPzZonATvNTkfjoLzBvX7vIsUUeT1ghCmiQkANGYPUkH 36LeLnO6wjoHKNjyp15BcAck2vIj0sxs5atoWnryhl1vP69UR0vz/YYJnb2cECMKLOL1 IFUHfN+63Y7jQaYTKshUdxxbtJMHQC5XtipXEwiLvdLnTC+H1dcW7v9JrSQJf0Hl4mDe 3I2sf9oxdqyYPNNMC/zaL4mijb5SOyz4wDceWRiYJD/6AQQsJkK/no2FxZrQZLpkAQ8s /zHCtKe/qkFZdxGw7iLuu3lVTOK883x6TWcbD2t5byojjB+EcqWBTs9HEEINsRsxfEcm tDkw== X-Gm-Message-State: AOAM531j8kptIx8l6uw734gkFc++qYnM2pllJS7RyRPxfO7Y660HO9JA 1V/eNAJfikJ4oTBepKGWZNfmKg== X-Google-Smtp-Source: ABdhPJwRkedATLb48/Qyk86sCwP/R09FC1QZdZqR1z4l79X/DpZVhYH90xVM3sNMepVmtjfx0i/5Ig== X-Received: by 2002:a17:902:a9cc:b0:161:3bf4:9047 with SMTP id b12-20020a170902a9cc00b001613bf49047mr25560810plr.137.1653369242211; Mon, 23 May 2022 22:14:02 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:11f3:53d3:b79a:52bd]) by smtp.gmail.com with ESMTPSA id g20-20020a625214000000b0050dc76281c4sm8115745pfb.158.2022.05.23.22.14.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 22:14:01 -0700 (PDT) Date: Mon, 23 May 2022 22:13:58 -0700 From: Fangrui Song To: Szabolcs Nagy Cc: libc-alpha@sourceware.org, Adhemerval Zanella Subject: Re: [PATCH 2/3] Revert "[AArch64][BZ #17711] Fix extern protected data handling" Message-ID: <20220524051358.bnuyx34ljcm7tneq@google.com> References: <20220501060615.1694317-1-maskray@google.com> <20220501060615.1694317-3-maskray@google.com> <20220523201730.guj45xljhi33c3wk@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20220523201730.guj45xljhi33c3wk@google.com> X-Spam-Status: No, score=-20.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, 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=ham 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 05:14:06 -0000 On 2022-05-23, Fangrui Song wrote: >On 2022-05-23, Szabolcs Nagy wrote: >>The 04/30/2022 23:06, Fangrui Song wrote: >>>This reverts commit 0910702c4d2cf9e8302b35c9519548726e1ac489. >>> >>>Say both a.so and b.so define protected var and the executable copy >>>relocates var. ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange >>>semantics: a.so accesses the copy in the executable while b.so accesses >>>its own. This behavior requires that (a) the compiler emits >>>GOT-generating relocations (b) the linker produces GLOB_DAT instead of >>>RELATIVE. >>> >>>Without the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA code, b.so's GLOB_DAT >>>will bind to the executable (normal behavior). >>> >>>For aarch64 it makes sense to restore the original behavior and don't >>>pay the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA cost. The behavior is very >>>unlikely used by anyone. >>> >>>* Clang code generation treats STV_PROTECTED the same way as STV_HIDDEN: >>> no GOT-generating relocation in the first place. >>>* 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. >> >>this looks fine. i guess bfd ld should warn/reject copy relocs too >>since it wont work well with protected visibility. >> >>Reviewed-by: Szabolcs Nagy > >Thanks for review. I'll check GNU ld's aarch64 port if I get time. I sent a GNU ld patch for review: https://sourceware.org/pipermail/binutils/2022-May/120970.html ("[PATCH] aarch64: Disallow copy relocations on protected data")