From patchwork Sun May 1 06:06:14 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Fangrui Song X-Patchwork-Id: 53372 X-Patchwork-Delegate: szabolcs.nagy@arm.com Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6E99A3857C4A for ; Sun, 1 May 2022 06:08:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E99A3857C4A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1651385290; bh=CrmHKNMoayCnSYFR2jMxHvcEqBJNssvBJQ9q7oRl6+U=; h=Date:In-Reply-To:References:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=IoS78tD6DK2zf2ZLU9zti1OPOSZDEtjwrW35xrW7CXF+5qer2BoZjbFXve8SHc8YQ GGRUsmYzXr3Rc5PP1SE8npmbrVPBxHmoolUINaIkxefKktrlwbqHv6eB/qkq+sgf76 tZ5vdqzm4/dkjSMMXKu2yHEtflFxox9TWNf8ESEQ= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by sourceware.org (Postfix) with ESMTPS id 541F43857815 for ; Sun, 1 May 2022 06:07:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 541F43857815 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-2f8be9326fcso49217757b3.18 for ; Sat, 30 Apr 2022 23:07:05 -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:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=CrmHKNMoayCnSYFR2jMxHvcEqBJNssvBJQ9q7oRl6+U=; b=Ql2F8ae6trtZkO5lbor3NPEvohKk8FYTxGlGHozm5VkYoYj02/xh+8MT9IWRXXHdvk AYuvo2FiLcOCoQDMPTLqbuetCudQz0sf/qSe273mo71k61wzUPPrWlwsgpE/OTGu3lRZ chr41q9r2GXRdILQX5aeJOBmjp9w4chGyIVRYbQ/byaEGJuj4EdrGDysbkHov8qrLiVF pFttCVNmJv9ExzW8SpKL8gGxqe8V4dH+kWikHW2CX7ANRXG9XW0JHkArJhDOMWLMNYiT eRtdM5ALh4zfRJNImMY2PvDRJ9snF3uUlMbQb60Fee175yih0XaalXkKIp8FZ8WHmxsJ RryA== X-Gm-Message-State: AOAM5302pLlE0d7oV/mPdrTQcpFKbiJmf2mWMk/7g7mnfxY9tEnHkUBr omNAtuX25MQ7eqT3T6/f61XjywnNhu5vP57/aJUWNsmJws8NBp0zbROPs9PKF/7ASgdY1zAxqkZ bmkWVIKJ8uARaGDXTLAYC9TTRmL/jIvKH/OA2MFqNXkZSITX4zVZkLO3ZDuGl5YWVHqjZ X-Google-Smtp-Source: ABdhPJxUjpCqhH/FAI1t6puveGPxsAJYJY97mSK/2geFoKd9xAf3Rw1kOD/hp9B8QPg+Dxn/QBgPOB5+5Uqk X-Received: from maskray1.svl.corp.google.com ([2620:15c:2ce:200:a6bd:e82a:7b1:cc1]) (user=maskray job=sendgmr) by 2002:a81:1901:0:b0:2f8:3983:78f7 with SMTP id 1-20020a811901000000b002f8398378f7mr6580512ywz.370.1651385224704; Sat, 30 Apr 2022 23:07:04 -0700 (PDT) Date: Sat, 30 Apr 2022 23:06:14 -0700 In-Reply-To: <20220501060615.1694317-1-maskray@google.com> Message-Id: <20220501060615.1694317-3-maskray@google.com> Mime-Version: 1.0 References: <20220501060615.1694317-1-maskray@google.com> Subject: [PATCH 2/3] Revert "[AArch64][BZ #17711] Fix extern protected data handling" To: libc-alpha@sourceware.org, Adhemerval Zanella , Szabolcs Nagy 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, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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-Patchwork-Original-From: Fangrui Song via Libc-alpha From: Fangrui Song Reply-To: Fangrui Song Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" 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. Reviewed-by: Szabolcs Nagy --- sysdeps/aarch64/dl-machine.h | 13 ++++++------- sysdeps/aarch64/dl-sysdep.h | 2 -- 2 files changed, 6 insertions(+), 9 deletions(-) diff --git a/sysdeps/aarch64/dl-machine.h b/sysdeps/aarch64/dl-machine.h index b40050a981..530952a736 100644 --- a/sysdeps/aarch64/dl-machine.h +++ b/sysdeps/aarch64/dl-machine.h @@ -182,13 +182,12 @@ _dl_start_user: \n\ "); #define elf_machine_type_class(type) \ - ((((type) == AARCH64_R(JUMP_SLOT) \ - || (type) == AARCH64_R(TLS_DTPMOD) \ - || (type) == AARCH64_R(TLS_DTPREL) \ - || (type) == AARCH64_R(TLS_TPREL) \ - || (type) == AARCH64_R(TLSDESC)) * ELF_RTYPE_CLASS_PLT) \ - | (((type) == AARCH64_R(COPY)) * ELF_RTYPE_CLASS_COPY) \ - | (((type) == AARCH64_R(GLOB_DAT)) * ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA)) + ((((type) == R_AARCH64_JUMP_SLOT || \ + (type) == R_AARCH64_TLS_DTPMOD || \ + (type) == R_AARCH64_TLS_DTPREL || \ + (type) == R_AARCH64_TLS_TPREL || \ + (type) == R_AARCH64_TLSDESC) * ELF_RTYPE_CLASS_PLT) \ + | (((type) == R_AARCH64_COPY) * ELF_RTYPE_CLASS_COPY)) #define ELF_MACHINE_JMP_SLOT AARCH64_R(JUMP_SLOT) diff --git a/sysdeps/aarch64/dl-sysdep.h b/sysdeps/aarch64/dl-sysdep.h index 667786671c..ac69f414f3 100644 --- a/sysdeps/aarch64/dl-sysdep.h +++ b/sysdeps/aarch64/dl-sysdep.h @@ -21,5 +21,3 @@ /* _dl_argv cannot be attribute_relro, because _dl_start_user might write into it after _dl_start returns. */ #define DL_ARGV_NOT_RELRO 1 - -#define DL_EXTERN_PROTECTED_DATA