From patchwork Sun May 1 06:06:12 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Fangrui Song X-Patchwork-Id: 53370 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 B48F73858C51 for ; Sun, 1 May 2022 06:06:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B48F73858C51 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1651385206; bh=zhqpOScfKg2up6BLOLgrVG1CsmoykW0oUXkQQHzgrcU=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=eczdVt7Td5qMEhz9xlWkiSsRRAM9gLphRtppOCkTjecxN9/yGTOzHyaXMtdw100pz MwjRFmnCrB1jn8+y2IC3b4zlNz8Vo6SQqxq30EpQ2rEIicIu3UHN009sJecO/Y2Jj2 GbPQbKyDfa6y+FCZqvXvi61dHYnY8FrpXuzObcK0= 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 73E423858D28 for ; Sun, 1 May 2022 06:06:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73E423858D28 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-2d11b6259adso111403637b3.19 for ; Sat, 30 Apr 2022 23:06:25 -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:message-id:mime-version:subject:from:to:cc; bh=zhqpOScfKg2up6BLOLgrVG1CsmoykW0oUXkQQHzgrcU=; b=0zfhSopw/gAPqQPjmqW91RZmQqb0UvaB3TEDbcJ5xk3olk3LZ7a3AStLolbNh4VlJn kiBoOzExwtDyh6SpGpo/Ic9J5kyxkBLQJGzR4oa9gDDllepL4WsVLmylIthT+m8GYSgo 2NAz2CobnmDrTBYzl98oVwp597aM9zMytEARJW5NjC9ASWXIFHYDYqdOQDtFRS17sgFe oQbLLldMXKdJrn50QY9/YtbSBPJHNi641H6P9YoZJm+f0M0t8TqyT8QwI5B7v+V+zcvl T0EfOxziQfLozZQkGWHoDq35HM86ZyV7oOuvSDp04jLRM+mJbBD0ioILAHbfRWm83j/0 oxXg== X-Gm-Message-State: AOAM5337rDfsd3rDIBM36YQKq9Q4a3A9gh646lhmb9BYgXVODsLL7+0e gyf7csVRaGxhb3FDpwMGgtCOf/0KXFeaEK+X8aIId7Qns4eRQUPXRky03pOkoBhu/DI7LCK3pdj LOXF6kkCq06M0mCFnx8rbbQJ17ExGMASyRmiL3ECpbuuLF8a90HLO2jzQ1MvG6ISDlMLB X-Google-Smtp-Source: ABdhPJwcs65figEf0L+g5HL08DDXHDQjHxlET05kANmVAm2uRaHRdu/xe/75rxJE1+X4iakCWKUf8J2MAg9m X-Received: from maskray1.svl.corp.google.com ([2620:15c:2ce:200:a6bd:e82a:7b1:cc1]) (user=maskray job=sendgmr) by 2002:a81:dc4:0:b0:2f7:d7a0:a491 with SMTP id 187-20020a810dc4000000b002f7d7a0a491mr6195754ywn.466.1651385184626; Sat, 30 Apr 2022 23:06:24 -0700 (PDT) Date: Sat, 30 Apr 2022 23:06:12 -0700 Message-Id: <20220501060615.1694317-1-maskray@google.com> Mime-Version: 1.0 Subject: [PATCH 0/3] Simplify ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA and revert aarch64/arm's extern protected data handling To: libc-alpha@sourceware.org, Adhemerval Zanella , Szabolcs Nagy X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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" 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/arm 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. Fangrui Song (3): elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA check for non-DL_EXTERN_PROTECTED_DATA ports Revert "[AArch64][BZ #17711] Fix extern protected data handling" Revert "[ARM][BZ #17711] Fix extern protected data handling" elf/dl-lookup.c | 46 ++++++++++++------------------------ sysdeps/aarch64/dl-machine.h | 13 +++++----- sysdeps/aarch64/dl-sysdep.h | 2 -- sysdeps/arm/dl-machine.h | 10 +++----- sysdeps/arm/dl-sysdep.h | 2 -- 5 files changed, 24 insertions(+), 49 deletions(-)